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

["jiale yao" <19888972804@163.com>]

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