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@xxxxxxx> wrote:
>At 2026-10-18 14:34:06, "Greg Kroah-Hartman" <gregkh@xxxxxxxxxxxxxxxxxxx> 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@xxxxxxx>
>>> ---
>>>  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@xxxxxxxxxxxxxxx

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