Re:Re: [PATCH] staging: vme_user: kill fake VIRQ tasklet on exit

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

Hi,
I have confirmed that the bug is still present in the latest development tree.

This bug is in vme_fake itself, which is a software-emulated VME bridge. 

No physical VME hardware is involved in this path, so real-hardware testing would not exercise the code that is failing here.

Thanks,
Jiale


At 2026-09-21 03:34:11, "Greg Kroah-Hartman" <gregkh@linuxfoundation.org> wrote:
>On Mon, Sep 21, 2026 at 01:02:21AM +0800, Jiale Yao wrote:
>> fake_irq_generate() schedules int_tasklet, which is embedded in struct
>> fake_driver and receives fake_bridge as its data argument. fake_exit()
>> frees both objects without waiting for a pending tasklet to complete.
>> 
>> This was reproduced on v6.18.52 under QEMU with the following sequence:
>
>6.18 is NOT the latest kernel release to be doing testing or development
>for.
>
>>   1. Load vme_fake and vme_user to create /dev/bus/vme/ctl.
>>   2. Issue VME_IRQ_GEN ioctls so fake_irq_generate() queues int_tasklet.
>>   3. Concurrently unload vme_fake before ksoftirqd runs the tasklet.
>>   4. fake_exit() frees the embedded tasklet and fake_bridge, after which
>>      tasklet_action_common() accesses the freed tasklet.
>> 
>> KASAN reported:
>> 
>>   BUG: KASAN: slab-use-after-free in tasklet_action_common+0xee/0x6f0
>>   Read of size 8 by task ksoftirqd/3/36
>> 
>>   Call Trace:
>>    <TASK>
>>    dump_stack_lvl+0x48/0x120
>>    print_report+0x191/0x580
>>    kasan_report+0x139/0x170
>>    tasklet_action_common+0xee/0x6f0
>>    handle_softirqs+0x159/0x4c0
>>    run_ksoftirqd+0x1c/0x30
>>    smpboot_thread_fn+0x385/0x700
>>    kthread+0x5c6/0x730
>>    ret_from_fork+0x15a/0x380
>>    ret_from_fork_asm+0x1a/0x30
>>    </TASK>
>> 
>> Unregister the bridge to remove the userspace entry point, then kill the
>> tasklet before tearing down the bridge resources. This ensures any pending
>> callback has completed before its storage and data argument are freed.
>
>What about on the real hardware?  As per our previous statements, that's
>the only way we can take LLM-found patches for staging drivers.
>
>thanks,
>
>greg k-h