mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
* [PATCH] regulator: cancel disable_work synchronously in regulator_unregister()
@ 2026-11-03 17:49 Chengyu Liu
  2026-11-04 12:39 ` Mark Brown
  2026-11-04 13:48 ` [PATCH v2] regulator: disable disable_work for good " Chengyu Liu
  0 siblings, 2 replies; 8+ messages in thread
From: Chengyu Liu @ 2026-11-03 17:49 UTC (permalink / raw)
  To: lgirdwood, broonie; +Cc: linux-kernel, Chengyu Liu, stable

regulator_unregister() stops rdev->disable_work with
flush_work(&dw->work), which is a no-op for a delayed_work pending on
the timer wheel: flush_work() only waits for a queued or running work
item.  A disable deferred by a consumer's regulator_disable_deferred()
therefore survives the provider's unbind, and regulator_disable_work()
fires after device_unregister() has freed the rdev, dereferencing it
via container_of().  Use-after-free.

The in-tree users are ASoC DAPM regulator widgets with a 20 ms
power-down delay (sound/soc/soc-dapm.c): the window is the entire
deferral period, not a race between adjacent instructions.

Use cancel_delayed_work_sync(), which also dequeues a timer-pending
instance, waits for a running callback and blocks re-arming.

Found by static analysis.

Cc: stable@vger.kernel.org
Signed-off-by: Chengyu Liu <lui2012qwq@gmail.com>
---
 drivers/regulator/core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index 6a4008f387..032b7298a5 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -6300,7 +6300,7 @@ void regulator_unregister(struct regulator_dev *rdev)
 		regulator_put(rdev->supply);
 	}
 
-	flush_work(&rdev->disable_work.work);
+	cancel_delayed_work_sync(&rdev->disable_work);
 
 	mutex_lock(&regulator_list_mutex);
 
-- 
2.25.1


^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH] regulator: cancel disable_work synchronously in regulator_unregister()
  2026-11-03 17:49 [PATCH] regulator: cancel disable_work synchronously in regulator_unregister() Chengyu Liu
@ 2026-11-04 12:39 ` Mark Brown
  2026-11-04 13:46   ` Chengyu Liu
  2026-11-04 13:48 ` [PATCH v2] regulator: disable disable_work for good " Chengyu Liu
  1 sibling, 1 reply; 8+ messages in thread
From: Mark Brown @ 2026-11-04 12:39 UTC (permalink / raw)
  To: Chengyu Liu; +Cc: lgirdwood, broonie, linux-kernel, stable

> Use cancel_delayed_work_sync(), which also dequeues a timer-pending
> instance, waits for a running callback and blocks re-arming.

I think you want disable_delayed_work_sync() here for the rearming part.

-- 
Mark Brown <broonie@kernel.org>

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH] regulator: cancel disable_work synchronously in regulator_unregister()
  2026-11-04 12:39 ` Mark Brown
@ 2026-11-04 13:46   ` Chengyu Liu
  0 siblings, 0 replies; 8+ messages in thread
From: Chengyu Liu @ 2026-11-04 13:46 UTC (permalink / raw)
  To: Mark Brown; +Cc: lgirdwood, linux-kernel, stable

On Tue, Nov 04, 2026 at 08:39:05PM +0000, Mark Brown wrote:
> I think you want disable_delayed_work_sync() here for the rearming part.

Agreed, that's a mistake in my patch. Thanks for pointing it out. I'll
send a v2 switching to disable_delayed_work_sync(), which keeps the
work disabled so a racing regulator_disable_deferred() can't re-arm it
during the teardown.

^ permalink raw reply	[flat|nested] 8+ messages in thread

* [PATCH v2] regulator: disable disable_work for good in regulator_unregister()
  2026-11-03 17:49 [PATCH] regulator: cancel disable_work synchronously in regulator_unregister() Chengyu Liu
  2026-11-04 12:39 ` Mark Brown
@ 2026-11-04 13:48 ` Chengyu Liu
  2026-11-04 13:53   ` Mark Brown
  1 sibling, 1 reply; 8+ messages in thread
From: Chengyu Liu @ 2026-11-04 13:48 UTC (permalink / raw)
  To: broonie; +Cc: lgirdwood, linux-kernel, stable, Chengyu Liu

regulator_unregister() stops rdev->disable_work with
flush_work(&dw->work), which is a no-op for a delayed_work pending on
the timer wheel: flush_work() only waits for a queued or running work
item.  A disable deferred by a consumer's regulator_disable_deferred()
therefore survives the provider's unbind, and regulator_disable_work()
fires after device_unregister() has freed the rdev, dereferencing it
via container_of().  Use-after-free.

The in-tree users are ASoC DAPM regulator widgets with a 20 ms
power-down delay (sound/soc/soc-dapm.c): the window is the entire
deferral period, not a race between adjacent instructions.

Use disable_delayed_work_sync(): it dequeues a timer-pending instance
and waits for a running callback, and keeps the work disabled so a
concurrent regulator_disable_deferred() cannot re-arm it while the
teardown proceeds.

Found by static analysis.

Cc: stable@vger.kernel.org
Signed-off-by: Chengyu Liu <lui2012qwq@gmail.com>
---
v2: switch to disable_delayed_work_sync() (Mark Brown): also keeps the
    work disabled so nothing can re-arm it past the teardown.

 drivers/regulator/core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index 6a4008f387b5..4ba0457c4747 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -6300,7 +6300,7 @@ void regulator_unregister(struct regulator_dev *rdev)
 		regulator_put(rdev->supply);
 	}
 
-	flush_work(&rdev->disable_work.work);
+	disable_delayed_work_sync(&rdev->disable_work);
 
 	mutex_lock(&regulator_list_mutex);
 
-- 
2.25.1


^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH v2] regulator: disable disable_work for good in regulator_unregister()
  2026-11-04 13:48 ` [PATCH v2] regulator: disable disable_work for good " Chengyu Liu
@ 2026-11-04 13:53   ` Mark Brown
  2026-11-04 13:58     ` Chengyu Liu
  0 siblings, 1 reply; 8+ messages in thread
From: Mark Brown @ 2026-11-04 13:53 UTC (permalink / raw)
  To: Chengyu Liu; +Cc: lgirdwood, linux-kernel, stable

[-- Attachment #1: Type: text/plain, Size: 804 bytes --]

On Wed, Nov 04, 2026 at 09:48:38PM +0800, Chengyu Liu wrote:
> regulator_unregister() stops rdev->disable_work with
> flush_work(&dw->work), which is a no-op for a delayed_work pending on
> the timer wheel: flush_work() only waits for a queued or running work
> item.  A disable deferred by a consumer's regulator_disable_deferred()
> therefore survives the provider's unbind, and regulator_disable_work()
> fires after device_unregister() has freed the rdev, dereferencing it
> via container_of().  Use-after-free.

Please don't send new patches in reply to old patches or serieses, this
makes it harder for both people and tools to understand what is going
on - it can bury things in mailboxes and make it difficult to keep track
of what current patches are, both for the new patches and the old ones.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH v2] regulator: disable disable_work for good in regulator_unregister()
  2026-11-04 13:53   ` Mark Brown
@ 2026-11-04 13:58     ` Chengyu Liu
  2026-11-04 14:44       ` Mark Brown
  0 siblings, 1 reply; 8+ messages in thread
From: Chengyu Liu @ 2026-11-04 13:58 UTC (permalink / raw)
  To: Mark Brown; +Cc: lgirdwood, linux-kernel, stable

On Wed, Nov 4, 2026 at 9:53 PM Mark Brown <broonie@kernel.org> wrote:
> Please don't send new patches in reply to old patches or serieses, this
> makes it harder for both people and tools to understand what is going
> on - it can bury things in mailboxes and make it difficult to keep track
> of what current patches are, both for the new patches and the old ones.

Understood, sorry about that - I'll repost v2 as a fresh thread with a
link to v1.

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH v2] regulator: disable disable_work for good in regulator_unregister()
  2026-11-04 13:58     ` Chengyu Liu
@ 2026-11-04 14:44       ` Mark Brown
  0 siblings, 0 replies; 8+ messages in thread
From: Mark Brown @ 2026-11-04 14:44 UTC (permalink / raw)
  To: Chengyu Liu; +Cc: lgirdwood, linux-kernel, stable

[-- Attachment #1: Type: text/plain, Size: 651 bytes --]

On Wed, Nov 04, 2026 at 09:58:35PM +0800, Chengyu Liu wrote:
> On Wed, Nov 4, 2026 at 9:53 PM Mark Brown <broonie@kernel.org> wrote:
> > Please don't send new patches in reply to old patches or serieses, this
> > makes it harder for both people and tools to understand what is going
> > on - it can bury things in mailboxes and make it difficult to keep track
> > of what current patches are, both for the new patches and the old ones.
> 
> Understood, sorry about that - I'll repost v2 as a fresh thread with a
> link to v1.

No, please don't do that - that will create even more confusion as there
will be multiple v2s floating about.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 8+ messages in thread

* [PATCH v2] regulator: disable disable_work for good in regulator_unregister()
@ 2026-11-04 14:07 Chengyu Liu
  0 siblings, 0 replies; 8+ messages in thread
From: Chengyu Liu @ 2026-11-04 14:07 UTC (permalink / raw)
  To: broonie; +Cc: lgirdwood, linux-kernel, stable, Chengyu Liu

regulator_unregister() stops rdev->disable_work with
flush_work(&dw->work), which is a no-op for a delayed_work pending on
the timer wheel: flush_work() only waits for a queued or running work
item.  A disable deferred by a consumer's regulator_disable_deferred()
therefore survives the provider's unbind, and regulator_disable_work()
fires after device_unregister() has freed the rdev, dereferencing it
via container_of().  Use-after-free.

The in-tree users are ASoC DAPM regulator widgets with a 20 ms
power-down delay (sound/soc/soc-dapm.c): the window is the entire
deferral period, not a race between adjacent instructions.

Use disable_delayed_work_sync(): it dequeues a timer-pending instance
and waits for a running callback, and keeps the work disabled so a
concurrent regulator_disable_deferred() cannot re-arm it while the
teardown proceeds.

Found by static analysis.

Cc: stable@vger.kernel.org
Signed-off-by: Chengyu Liu <lui2012qwq@gmail.com>
---
v2: switch to disable_delayed_work_sync() (Mark Brown): also keeps the
    work disabled so nothing can re-arm it past the teardown.

v1: https://lore.kernel.org/r/20261103174911.1600930-1-lui2012qwq@gmail.com

 drivers/regulator/core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index 6a4008f387b5..4ba0457c4747 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -6300,7 +6300,7 @@ void regulator_unregister(struct regulator_dev *rdev)
 		regulator_put(rdev->supply);
 	}
 
-	flush_work(&rdev->disable_work.work);
+	disable_delayed_work_sync(&rdev->disable_work);
 
 	mutex_lock(&regulator_list_mutex);
 
-- 
2.25.1


^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2026-11-04 14:44 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2026-11-03 17:49 [PATCH] regulator: cancel disable_work synchronously in regulator_unregister() Chengyu Liu
2026-11-04 12:39 ` Mark Brown
2026-11-04 13:46   ` Chengyu Liu
2026-11-04 13:48 ` [PATCH v2] regulator: disable disable_work for good " Chengyu Liu
2026-11-04 13:53   ` Mark Brown
2026-11-04 13:58     ` Chengyu Liu
2026-11-04 14:44       ` Mark Brown
2026-11-04 14:07 Chengyu Liu

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®