[PATCH v2] regulator: disable disable_work for good in regulator_unregister()

[PATCH v2] regulator: disable disable_work for good in regulator_unregister()

[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

[PATCH] regulator: cancel disable_work synchronously in regulator_unregister()

[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 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

[PATCH v2] regulator: disable disable_work for good in regulator_unregister()

[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

Re: [PATCH v2] regulator: disable disable_work for good in regulator_unregister()

[Mark Brown]

[-- 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 --]

Re: [PATCH v2] regulator: disable disable_work for good in regulator_unregister()

[Chengyu Liu]

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.

Re: [PATCH v2] regulator: disable disable_work for good in regulator_unregister()

[Mark Brown]

[-- 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 --]