[PATCH] mmc: vub300: fix sleeping function call from invalid context in vub300_inactivity_timer_expired

[PATCH] mmc: vub300: fix sleeping function call from invalid context in vub300_inactivity_timer_expired

[Jakov Novak]

 Currently, the function vub300_inactivity_timer_expired, which gets
 called in a softirq context, calls a sleeping function in the following
 call chain:

 vub300_inactivity_timer_expired -> kref_put -> vub300_delete ->
 mmc_free_host -> cancel_delayed_work_sync -> __cancel_work_sync ->
 might_sleep -> BUG

 Fix this by replacing kref_put(&vub300->kref, vub300_delete) with
 vub300_queue_dead_work(vub300), which does the same thing, but in a
 workqueue context.

Fixes: 88095e7b473a ("mmc: Add new VUB300 USB-to-SD/SDIO/MMC driver")
Reported-and-tested-by: syzbot+1ee4f3b9228e35f14677@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=1ee4f3b9228e35f14677
Signed-off-by: Jakov Novak <jakovnovak30@gmail.com>
---
 drivers/mmc/host/vub300.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mmc/host/vub300.c b/drivers/mmc/host/vub300.c
index 2dae474dcd06..df0096bc53db 100644
--- a/drivers/mmc/host/vub300.c
+++ b/drivers/mmc/host/vub300.c
@@ -744,7 +744,7 @@ static void vub300_inactivity_timer_expired(struct timer_list *t)
 	struct vub300_mmc_host *vub300 = timer_container_of(vub300, t,
 							    inactivity_timer);
 	if (!vub300->interface) {
-		kref_put(&vub300->kref, vub300_delete);
+		vub300_queue_dead_work(vub300);
 	} else if (vub300->cmd) {
 		mod_timer(&vub300->inactivity_timer, jiffies + HZ);
 	} else {
-- 
2.55.0

Re: [PATCH] mmc: vub300: fix sleeping function call from invalid context in vub300_inactivity_timer_expired

[Johan Hovold]

[ +CC: Geert ]

On Sun, Aug 16, 2026 at 05:38:09PM +0200, Jakov Novak wrote:
>  Currently, the function vub300_inactivity_timer_expired, which gets
>  called in a softirq context, calls a sleeping function in the following
>  call chain:
> 
>  vub300_inactivity_timer_expired -> kref_put -> vub300_delete ->
>  mmc_free_host -> cancel_delayed_work_sync -> __cancel_work_sync ->
>  might_sleep -> BUG
> 
>  Fix this by replacing kref_put(&vub300->kref, vub300_delete) with
>  vub300_queue_dead_work(vub300), which does the same thing, but in a
>  workqueue context.
> 
> Fixes: 88095e7b473a ("mmc: Add new VUB300 USB-to-SD/SDIO/MMC driver")

This isn't the commit that introduced the issue. The blocking call in
mmc_free_host() was added by commit 1036f69e2513 ("mmc: core: Cancel
delayed work before releasing host") in 2023. 

I didn't look at this in any detail, but having that call in
mmc_free_host() (e.g. rather than in mmc_remove_host()) looks wrong so
perhaps the fix really lies in MMC core.

> Reported-and-tested-by: syzbot+1ee4f3b9228e35f14677@syzkaller.appspotmail.com

Not sure if syzbot has started suggesting this tag, but this should
be two separate tags.

> Closes: https://syzkaller.appspot.com/bug?extid=1ee4f3b9228e35f14677
> Signed-off-by: Jakov Novak <jakovnovak30@gmail.com>
> ---
>  drivers/mmc/host/vub300.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/mmc/host/vub300.c b/drivers/mmc/host/vub300.c
> index 2dae474dcd06..df0096bc53db 100644
> --- a/drivers/mmc/host/vub300.c
> +++ b/drivers/mmc/host/vub300.c
> @@ -744,7 +744,7 @@ static void vub300_inactivity_timer_expired(struct timer_list *t)
>  	struct vub300_mmc_host *vub300 = timer_container_of(vub300, t,
>  							    inactivity_timer);
>  	if (!vub300->interface) {
> -		kref_put(&vub300->kref, vub300_delete);
> +		vub300_queue_dead_work(vub300);
>  	} else if (vub300->cmd) {
>  		mod_timer(&vub300->inactivity_timer, jiffies + HZ);
>  	} else {

Johan

Re: [PATCH] mmc: vub300: fix sleeping function call from invalid context in vub300_inactivity_timer_expired

[Tetsuo Handa]

On 2026/08/17 17:13, Johan Hovold wrote:
> I didn't look at this in any detail, but having that call in
> mmc_free_host() (e.g. rather than in mmc_remove_host()) looks wrong so
> perhaps the fix really lies in MMC core.

syzbot has an AI-generated patch at
https://lkml.kernel.org/r/49982079-95f4-4e8c-bbbc-bcb127e2f378@mail.kernel.org .

Please check.

Re: [PATCH] mmc: vub300: fix sleeping function call from invalid context in vub300_inactivity_timer_expired

[Jakov Novak]

> syzbot has an AI-generated patch at
> https://lkml.kernel.org/r/49982079-95f4-4e8c-bbbc-bcb127e2f378@mail.kernel.org .
>
> Please check.
I checked the AI-generated patch and it just uses the deadworkqueue in a
new function. That is the same thing I am doing except that I'm using
the vub300_queue_dead_work function instead of writing some new code
that does the same thing.

The real question is whether mmc_free_host should be allowed to invoke
the sleep function or not. Geert needs to elaborate on that since he
added this change in 1036f69e2513 ("mmc: core: Cancel
delayed work before releasing host").

Re: [PATCH] mmc: vub300: fix sleeping function call from invalid context in vub300_inactivity_timer_expired

[Geert Uytterhoeven]

Hi Jakov,

On Mon, 7 Sept 2026 at 13:18, Jakov Novak <jakovnovak30@gmail.com> wrote:
> > syzbot has an AI-generated patch at
> > https://lkml.kernel.org/r/49982079-95f4-4e8c-bbbc-bcb127e2f378@mail.kernel.org .
> >
> > Please check.
> I checked the AI-generated patch and it just uses the deadworkqueue in a
> new function. That is the same thing I am doing except that I'm using
> the vub300_queue_dead_work function instead of writing some new code
> that does the same thing.
>
> The real question is whether mmc_free_host should be allowed to invoke
> the sleep function or not. Geert needs to elaborate on that since he
> added this change in 1036f69e2513 ("mmc: core: Cancel
> delayed work before releasing host").

Why would this not be allowed?
This is just in the driver remove or probe error path.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH] mmc: vub300: fix sleeping function call from invalid context in vub300_inactivity_timer_expired

[Geert Uytterhoeven]

Hi Johan,

On Mon, 17 Aug 2026 at 10:13, Johan Hovold <johan@kernel.org> wrote:
> On Sun, Aug 16, 2026 at 05:38:09PM +0200, Jakov Novak wrote:
> >  Currently, the function vub300_inactivity_timer_expired, which gets
> >  called in a softirq context, calls a sleeping function in the following
> >  call chain:
> >
> >  vub300_inactivity_timer_expired -> kref_put -> vub300_delete ->
> >  mmc_free_host -> cancel_delayed_work_sync -> __cancel_work_sync ->
> >  might_sleep -> BUG
> >
> >  Fix this by replacing kref_put(&vub300->kref, vub300_delete) with
> >  vub300_queue_dead_work(vub300), which does the same thing, but in a
> >  workqueue context.
> >
> > Fixes: 88095e7b473a ("mmc: Add new VUB300 USB-to-SD/SDIO/MMC driver")
>
> This isn't the commit that introduced the issue. The blocking call in
> mmc_free_host() was added by commit 1036f69e2513 ("mmc: core: Cancel
> delayed work before releasing host") in 2023.
>
> I didn't look at this in any detail, but having that call in
> mmc_free_host() (e.g. rather than in mmc_remove_host()) looks wrong so
> perhaps the fix really lies in MMC core.

mmc_remove_host() can only be called after a sucessful probe, while
commit 1036f69e2513 fixed an issue where the last probe step failed
with -EPROBE_DEFER.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH] mmc: vub300: fix sleeping function call from invalid context in vub300_inactivity_timer_expired

[Johan Hovold]

Hi Geert,

On Mon, Sep 07, 2026 at 02:17:45PM +0200, Geert Uytterhoeven wrote:
> Hi Johan,
> 
> On Mon, 17 Aug 2026 at 10:13, Johan Hovold <johan@kernel.org> wrote:
> > On Sun, Aug 16, 2026 at 05:38:09PM +0200, Jakov Novak wrote:
> > >  Currently, the function vub300_inactivity_timer_expired, which gets
> > >  called in a softirq context, calls a sleeping function in the following
> > >  call chain:
> > >
> > >  vub300_inactivity_timer_expired -> kref_put -> vub300_delete ->
> > >  mmc_free_host -> cancel_delayed_work_sync -> __cancel_work_sync ->
> > >  might_sleep -> BUG
> > >
> > >  Fix this by replacing kref_put(&vub300->kref, vub300_delete) with
> > >  vub300_queue_dead_work(vub300), which does the same thing, but in a
> > >  workqueue context.
> > >
> > > Fixes: 88095e7b473a ("mmc: Add new VUB300 USB-to-SD/SDIO/MMC driver")
> >
> > This isn't the commit that introduced the issue. The blocking call in
> > mmc_free_host() was added by commit 1036f69e2513 ("mmc: core: Cancel
> > delayed work before releasing host") in 2023.
> >
> > I didn't look at this in any detail, but having that call in
> > mmc_free_host() (e.g. rather than in mmc_remove_host()) looks wrong so
> > perhaps the fix really lies in MMC core.
> 
> mmc_remove_host() can only be called after a sucessful probe, while
> commit 1036f69e2513 fixed an issue where the last probe step failed
> with -EPROBE_DEFER.

Sure, but should you be scheduling rescan work before all resources have
been set up and the host has been registered?

Johan

Re: [PATCH] mmc: vub300: fix sleeping function call from invalid context in vub300_inactivity_timer_expired

[Geert Uytterhoeven]

Hi Johan,

On Mon, 7 Sept 2026 at 15:55, Johan Hovold <johan@kernel.org> wrote:
> On Mon, Sep 07, 2026 at 02:17:45PM +0200, Geert Uytterhoeven wrote:
> > On Mon, 17 Aug 2026 at 10:13, Johan Hovold <johan@kernel.org> wrote:
> > > On Sun, Aug 16, 2026 at 05:38:09PM +0200, Jakov Novak wrote:
> > > >  Currently, the function vub300_inactivity_timer_expired, which gets
> > > >  called in a softirq context, calls a sleeping function in the following
> > > >  call chain:
> > > >
> > > >  vub300_inactivity_timer_expired -> kref_put -> vub300_delete ->
> > > >  mmc_free_host -> cancel_delayed_work_sync -> __cancel_work_sync ->
> > > >  might_sleep -> BUG
> > > >
> > > >  Fix this by replacing kref_put(&vub300->kref, vub300_delete) with
> > > >  vub300_queue_dead_work(vub300), which does the same thing, but in a
> > > >  workqueue context.
> > > >
> > > > Fixes: 88095e7b473a ("mmc: Add new VUB300 USB-to-SD/SDIO/MMC driver")
> > >
> > > This isn't the commit that introduced the issue. The blocking call in
> > > mmc_free_host() was added by commit 1036f69e2513 ("mmc: core: Cancel
> > > delayed work before releasing host") in 2023.
> > >
> > > I didn't look at this in any detail, but having that call in
> > > mmc_free_host() (e.g. rather than in mmc_remove_host()) looks wrong so
> > > perhaps the fix really lies in MMC core.
> >
> > mmc_remove_host() can only be called after a sucessful probe, while
> > commit 1036f69e2513 fixed an issue where the last probe step failed
> > with -EPROBE_DEFER.
>
> Sure, but should you be scheduling rescan work before all resources have
> been set up and the host has been registered?

I would like to defer that question to the TMIO experts.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH] mmc: vub300: fix sleeping function call from invalid context in vub300_inactivity_timer_expired

[Johan Hovold]

On Mon, Sep 07, 2026 at 04:48:00PM +0200, Geert Uytterhoeven wrote:
> Hi Johan,
> 
> On Mon, 7 Sept 2026 at 15:55, Johan Hovold <johan@kernel.org> wrote:
> > On Mon, Sep 07, 2026 at 02:17:45PM +0200, Geert Uytterhoeven wrote:
> > > On Mon, 17 Aug 2026 at 10:13, Johan Hovold <johan@kernel.org> wrote:
> > > > On Sun, Aug 16, 2026 at 05:38:09PM +0200, Jakov Novak wrote:
> > > > >  Currently, the function vub300_inactivity_timer_expired, which gets
> > > > >  called in a softirq context, calls a sleeping function in the following
> > > > >  call chain:
> > > > >
> > > > >  vub300_inactivity_timer_expired -> kref_put -> vub300_delete ->
> > > > >  mmc_free_host -> cancel_delayed_work_sync -> __cancel_work_sync ->
> > > > >  might_sleep -> BUG
> > > > >
> > > > >  Fix this by replacing kref_put(&vub300->kref, vub300_delete) with
> > > > >  vub300_queue_dead_work(vub300), which does the same thing, but in a
> > > > >  workqueue context.
> > > > >
> > > > > Fixes: 88095e7b473a ("mmc: Add new VUB300 USB-to-SD/SDIO/MMC driver")
> > > >
> > > > This isn't the commit that introduced the issue. The blocking call in
> > > > mmc_free_host() was added by commit 1036f69e2513 ("mmc: core: Cancel
> > > > delayed work before releasing host") in 2023.
> > > >
> > > > I didn't look at this in any detail, but having that call in
> > > > mmc_free_host() (e.g. rather than in mmc_remove_host()) looks wrong so
> > > > perhaps the fix really lies in MMC core.
> > >
> > > mmc_remove_host() can only be called after a sucessful probe, while
> > > commit 1036f69e2513 fixed an issue where the last probe step failed
> > > with -EPROBE_DEFER.
> >
> > Sure, but should you be scheduling rescan work before all resources have
> > been set up and the host has been registered?
> 
> I would like to defer that question to the TMIO experts.

Are they on CC?

Ulf, perhaps you can take a look at this? It seems wrong to enable
interrupts and trigger rescans before the host controller has been set
up and registered.

Johan

Re: [PATCH] mmc: vub300: fix sleeping function call from invalid context in vub300_inactivity_timer_expired

[Geert Uytterhoeven]

Hi Johan,

On Wed, 9 Sept 2026 at 08:57, Johan Hovold <johan@kernel.org> wrote:
> On Mon, Sep 07, 2026 at 04:48:00PM +0200, Geert Uytterhoeven wrote:
> > On Mon, 7 Sept 2026 at 15:55, Johan Hovold <johan@kernel.org> wrote:
> > > Sure, but should you be scheduling rescan work before all resources have
> > > been set up and the host has been registered?
> >
> > I would like to defer that question to the TMIO experts.
>
> Are they on CC?

Ulf was from the beginning; I had added Wolfram in my previous email.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH] mmc: vub300: fix sleeping function call from invalid context in vub300_inactivity_timer_expired

[Johan Hovold]

On Wed, Sep 09, 2026 at 09:38:24AM +0200, Geert Uytterhoeven wrote:
> On Wed, 9 Sept 2026 at 08:57, Johan Hovold <johan@kernel.org> wrote:
> > On Mon, Sep 07, 2026 at 04:48:00PM +0200, Geert Uytterhoeven wrote:
> > > On Mon, 7 Sept 2026 at 15:55, Johan Hovold <johan@kernel.org> wrote:
> > > > Sure, but should you be scheduling rescan work before all resources have
> > > > been set up and the host has been registered?
> > >
> > > I would like to defer that question to the TMIO experts.
> >
> > Are they on CC?
> 
> Ulf was from the beginning; I had added Wolfram in my previous email.

Thanks for clarifying.

Johan

Re: [PATCH] mmc: vub300: fix sleeping function call from invalid context in vub300_inactivity_timer_expired

[Wolfram Sang]

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


> > > Sure, but should you be scheduling rescan work before all resources have
> > > been set up and the host has been registered?
> > 
> > I would like to defer that question to the TMIO experts.

From a high level view, independently of TMIO/SDHI...

> Are they on CC?
> 
> Ulf, perhaps you can take a look at this? It seems wrong to enable
> interrupts and trigger rescans before the host controller has been set
> up and registered.

... it is always a good practice to enable irqs only when the device is
fully set up. From a glimpse, this seems to be the case here as well.

It needs serious testing, though. SDHI is a complex, organically grown
mass of code. There might be subtle side effects. It should still be
worth it IMO. I can put it on my todo list, but no promises...


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

Re: [PATCH] mmc: vub300: fix sleeping function call from invalid context in vub300_inactivity_timer_expired

[Johan Hovold]

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

On Wed, Sep 09, 2026 at 07:24:46PM +0200, Wolfram Sang wrote:
> 
> > > > Sure, but should you be scheduling rescan work before all resources have
> > > > been set up and the host has been registered?
> > > 
> > > I would like to defer that question to the TMIO experts.
> 
> From a high level view, independently of TMIO/SDHI...
> 
> > Are they on CC?
> > 
> > Ulf, perhaps you can take a look at this? It seems wrong to enable
> > interrupts and trigger rescans before the host controller has been set
> > up and registered.
> 
> ... it is always a good practice to enable irqs only when the device is
> fully set up. From a glimpse, this seems to be the case here as well.
> 
> It needs serious testing, though. SDHI is a complex, organically grown
> mass of code. There might be subtle side effects. It should still be
> worth it IMO. I can put it on my todo list, but no promises...

Thanks for taking a look. I guess we should fix this inconsistency in
MMC core eventually, but that the vub300 needs to be reworked to handle
this quirk in the mean time.

If only to stop the flood of LLM generated fixes to the syzbot report...

Johan

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

Re: [PATCH] mmc: vub300: fix sleeping function call from invalid context in vub300_inactivity_timer_expired

[Jakov Novak]

Hi Johan,

> Thanks for taking a look. I guess we should fix this inconsistency in
> MMC core eventually, but that the vub300 needs to be reworked to handle
> this quirk in the mean time.

Should I send a v2 based on my first patch with the Reported-by,
Tested-by and Fixes tags fixed or is there something else I missed? 

Best,
Jakov