[PATCH] bus: mhi: ep: cancel reset work during controller teardown

[PATCH] bus: mhi: ep: cancel reset work during controller teardown

[Jiale Yao]

The doorbell IRQ schedules reset_work on the system workqueue when the
host requests an MHI reset. The controller teardown only drains the
private MHI workqueue before releasing the controller state, so
reset_work can still run after that state has been freed.

Cancel reset_work before destroying the private workqueue and releasing
the controller resources. The caller is required to power down the
controller first, so the IRQ can no longer queue the work at this point.

Fixes: 7a97b6b47353 ("bus: mhi: ep: Add support for handling MHI_RESET")
Signed-off-by: Jiale Yao <yaojiale02@163.com>
---
 drivers/bus/mhi/ep/main.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/bus/mhi/ep/main.c b/drivers/bus/mhi/ep/main.c
index db7ee6547eef..a9695e1a75ab 100644
--- a/drivers/bus/mhi/ep/main.c
+++ b/drivers/bus/mhi/ep/main.c
@@ -1596,6 +1596,7 @@ void mhi_ep_unregister_controller(struct mhi_ep_cntrl *mhi_cntrl)
 {
 	struct mhi_ep_device *mhi_dev = mhi_cntrl->mhi_dev;
 
+	cancel_work_sync(&mhi_cntrl->reset_work);
 	destroy_workqueue(mhi_cntrl->wq);
 
 	free_irq(mhi_cntrl->irq, mhi_cntrl);
-- 
2.34.1

Re: [PATCH] bus: mhi: ep: cancel reset work during controller teardown

[Greg Kroah-Hartman]

On Sun, Oct 18, 2026 at 12:06:14PM +0800, Jiale Yao wrote:
> The doorbell IRQ schedules reset_work on the system workqueue when the
> host requests an MHI reset. The controller teardown only drains the
> private MHI workqueue before releasing the controller state, so
> reset_work can still run after that state has been freed.
> 
> Cancel reset_work before destroying the private workqueue and releasing
> the controller resources. The caller is required to power down the
> controller first, so the IRQ can no longer queue the work at this point.
> 
> Fixes: 7a97b6b47353 ("bus: mhi: ep: Add support for handling MHI_RESET")
> Signed-off-by: Jiale Yao <yaojiale02@163.com>
> ---
>  drivers/bus/mhi/ep/main.c | 1 +
>  1 file changed, 1 insertion(+)

How was this found and tested?  What about a cc: stable?

thanks,

greg k-h

Re:Re: [PATCH] bus: mhi: ep: cancel reset work during controller teardown

[jiale yao]

At 2026-10-18 14:34:06, "Greg Kroah-Hartman" <gregkh@linuxfoundation.org> wrote:
>On Sun, Oct 18, 2026 at 12:06:14PM +0800, Jiale Yao wrote:
>> The doorbell IRQ schedules reset_work on the system workqueue when the
>> host requests an MHI reset. The controller teardown only drains the
>> private MHI workqueue before releasing the controller state, so
>> reset_work can still run after that state has been freed.
>> 
>> Cancel reset_work before destroying the private workqueue and releasing
>> the controller resources. The caller is required to power down the
>> controller first, so the IRQ can no longer queue the work at this point.
>> 
>> Fixes: 7a97b6b47353 ("bus: mhi: ep: Add support for handling MHI_RESET")
>> Signed-off-by: Jiale Yao <yaojiale02@163.com>
>> ---
>>  drivers/bus/mhi/ep/main.c | 1 +
>>  1 file changed, 1 insertion(+)
>
>How was this found and tested?  What about a cc: stable?

cc:stable is necessory. The bug was found by my static analysis tools.

To test it, I registered a real mhi_ep_cntrl from a small out-of-tree module(software IRQ + fake register file),
drove the real mhi_ep_irq() and the real mhi_ep_unregister_controller(), and ordered the worker to run after
the frees. No kernel source changes.

KASAN:

BUG: KASAN: slab-use-after-free in mhi_ep_ring_init+0x192/0x240
Write of size 4 at addr ffff888104257118 by task kworker/0:1/11

CPU: 0 UID: 0 PID: 11 Comm: kworker/0:1 Tainted: G        W  O        7.3.0-rc4 #3 PREEMPT(lazy)
Tainted: [W]=WARN, [O]=OOT_MODULE
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
Workqueue: events mhi_ep_reset_worker
Call Trace:
 <TASK>
 dump_stack_lvl+0x2d/0x70
 print_report+0x175/0x7d0
 ? mhi_ep_ring_init+0x192/0x240
 kasan_report+0x139/0x170
 ? mhi_ep_ring_init+0x192/0x240
 mhi_ep_ring_init+0x192/0x240
 mhi_ep_power_up+0x10e/0xa70
 ? mutex_unlock+0x6b/0xc0
 process_scheduled_works+0x7c0/0xf10
 worker_thread+0x898/0xc50
 ? _raw_spin_lock_irqsave+0x6f/0x130
 kthread+0x2e9/0x3c0
 ? __pfx_worker_thread+0x10/0x10
 ? __pfx_kthread+0x10/0x10
 ret_from_fork+0x188/0x4f0
 ? __pfx_kthread+0x10/0x10
 ret_from_fork_asm+0x1a/0x30
 </TASK>

Allocated by task 81:
 kasan_save_track+0x3f/0x80
 __kasan_kmalloc+0x72/0x90
 mhi_ep_register_controller+0x593/0x1040

Freed by task 82:
 kasan_save_track+0x3f/0x80
 kasan_save_free_info+0x40/0x50
 __kasan_slab_free+0x3a/0x60
 kfree+0x10d/0x3b0
 mhi_ep_unregister_controller+0x112/0x1a0

The buggy address belongs to the object at ffff888104257100
 which belongs to the cache kmalloc-192 of size 192
The buggy address is located 24 bytes inside of
 freed 192-byte region [ffff888104257100, ffff8881042571c0)

Memory state around the buggy address:
 ffff888104257000: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
 ffff888104257080: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
>ffff888104257100: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
                            ^
 ffff888104257180: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
 ffff888104257200: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
==================================================================

Allocation in mhi_ep_register_controller(), free in mhi_ep_unregister_controller(),
access on Workqueue: events mhi_ep_reset_worker.

>
>thanks,
>
>greg k-h

Re:Re:Re: [PATCH] bus: mhi: ep: cancel reset work during controller teardown

[jiale yao]

At 2026-10-18 19:12:39, "jiale yao" <19888972804@163.com> wrote:
>At 2026-10-18 14:34:06, "Greg Kroah-Hartman" <gregkh@linuxfoundation.org> wrote:
>>On Sun, Oct 18, 2026 at 12:06:14PM +0800, Jiale Yao wrote:
>>> The doorbell IRQ schedules reset_work on the system workqueue when the
>>> host requests an MHI reset. The controller teardown only drains the
>>> private MHI workqueue before releasing the controller state, so
>>> reset_work can still run after that state has been freed.
>>> 
>>> Cancel reset_work before destroying the private workqueue and releasing
>>> the controller resources. The caller is required to power down the
>>> controller first, so the IRQ can no longer queue the work at this point.
>>> 
>>> Fixes: 7a97b6b47353 ("bus: mhi: ep: Add support for handling MHI_RESET")
>>> Signed-off-by: Jiale Yao <yaojiale02@163.com>
>>> ---
>>>  drivers/bus/mhi/ep/main.c | 1 +
>>>  1 file changed, 1 insertion(+)
>>
>>How was this found and tested?  What about a cc: stable?
>
>cc:stable is necessory. The bug was found by my static analysis tools.

Cc: stable@vger.kernel.org

>
>To test it, I registered a real mhi_ep_cntrl from a small out-of-tree module(software IRQ + fake register file),
>drove the real mhi_ep_irq() and the real mhi_ep_unregister_controller(), and ordered the worker to run after
>the frees. No kernel source changes.
>
>KASAN:
>
>BUG: KASAN: slab-use-after-free in mhi_ep_ring_init+0x192/0x240
>Write of size 4 at addr ffff888104257118 by task kworker/0:1/11
>
>CPU: 0 UID: 0 PID: 11 Comm: kworker/0:1 Tainted: G        W  O        7.3.0-rc4 #3 PREEMPT(lazy)
>Tainted: [W]=WARN, [O]=OOT_MODULE
>Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
>Workqueue: events mhi_ep_reset_worker
>Call Trace:
> <TASK>
> dump_stack_lvl+0x2d/0x70
> print_report+0x175/0x7d0
> ? mhi_ep_ring_init+0x192/0x240
> kasan_report+0x139/0x170
> ? mhi_ep_ring_init+0x192/0x240
> mhi_ep_ring_init+0x192/0x240
> mhi_ep_power_up+0x10e/0xa70
> ? mutex_unlock+0x6b/0xc0
> process_scheduled_works+0x7c0/0xf10
> worker_thread+0x898/0xc50
> ? _raw_spin_lock_irqsave+0x6f/0x130
> kthread+0x2e9/0x3c0
> ? __pfx_worker_thread+0x10/0x10
> ? __pfx_kthread+0x10/0x10
> ret_from_fork+0x188/0x4f0
> ? __pfx_kthread+0x10/0x10
> ret_from_fork_asm+0x1a/0x30
> </TASK>
>
>Allocated by task 81:
> kasan_save_track+0x3f/0x80
> __kasan_kmalloc+0x72/0x90
> mhi_ep_register_controller+0x593/0x1040
>
>Freed by task 82:
> kasan_save_track+0x3f/0x80
> kasan_save_free_info+0x40/0x50
> __kasan_slab_free+0x3a/0x60
> kfree+0x10d/0x3b0
> mhi_ep_unregister_controller+0x112/0x1a0
>
>The buggy address belongs to the object at ffff888104257100
> which belongs to the cache kmalloc-192 of size 192
>The buggy address is located 24 bytes inside of
> freed 192-byte region [ffff888104257100, ffff8881042571c0)
>
>Memory state around the buggy address:
> ffff888104257000: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> ffff888104257080: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
>>ffff888104257100: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>                            ^
> ffff888104257180: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
> ffff888104257200: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>==================================================================
>
>Allocation in mhi_ep_register_controller(), free in mhi_ep_unregister_controller(),
>access on Workqueue: events mhi_ep_reset_worker.
>
>>
>>thanks,
>>
>>greg k-h

Re: Re: [PATCH] bus: mhi: ep: cancel reset work during controller teardown

[Greg Kroah-Hartman]

On Sun, Oct 18, 2026 at 07:12:39PM +0800, jiale yao wrote:
> At 2026-10-18 14:34:06, "Greg Kroah-Hartman" <gregkh@linuxfoundation.org> wrote:
> >On Sun, Oct 18, 2026 at 12:06:14PM +0800, Jiale Yao wrote:
> >> The doorbell IRQ schedules reset_work on the system workqueue when the
> >> host requests an MHI reset. The controller teardown only drains the
> >> private MHI workqueue before releasing the controller state, so
> >> reset_work can still run after that state has been freed.
> >> 
> >> Cancel reset_work before destroying the private workqueue and releasing
> >> the controller resources. The caller is required to power down the
> >> controller first, so the IRQ can no longer queue the work at this point.
> >> 
> >> Fixes: 7a97b6b47353 ("bus: mhi: ep: Add support for handling MHI_RESET")
> >> Signed-off-by: Jiale Yao <yaojiale02@163.com>
> >> ---
> >>  drivers/bus/mhi/ep/main.c | 1 +
> >>  1 file changed, 1 insertion(+)
> >
> >How was this found and tested?  What about a cc: stable?
> 
> cc:stable is necessory. The bug was found by my static analysis tools.

Then as per our documentation you need to state that, right?