Re: [BUG] Double-free in blk_mq_free_sched_tags() after commit f5a6604f7a44

[Nilay Shroff <nilay@linux.ibm.com>]

On 9/28/25 6:48 PM, Ming Lei wrote:
> On Sun, Sep 28, 2025 at 8:18 PM Niklas Fischer <niklas@niklasfi.de> wrote:
>>
>> Hello,
>>
>> I'm reporting a kernel crash that occurs during boot on systems with
>> multiple storage devices. The issue manifests as a double-free bug in
>> the SLUB allocator, triggered by block layer elevator switching code.
>>
>> === Problem Summary ===
>>
>> The system crashes during early boot when udev configures I/O schedulers
>> on multiple storage devices. The crash occurs in mm/slub.c with a
>> double-free detection, traced back to blk_mq_free_sched_tags().
>>
>> === Crash Details ===
>>
>> Multiple crashes occur during boot, showing a severe race condition.
>> Seven separate kernel oops/panics are observed:
>>
>> * Oops #1 (CPU 13, PID 928): General protection fault in
>> kfree+0x69/0x3b0 - corrupted address 0x14b9d856a995288
>> * Oops #2-4, #6-7 (multiple CPUs/PIDs): kernel BUG at mm/slub.c:546 in
>> __slab_free+0x111/0x2a0 - SLUB double-free detection
>> * Oops #5 (CPU 1, PID 952): General protection fault in kfree+0x69/0x3b0
>>     - corrupted address 0x2480af562995288
>>
>> All crashes share the same call stack pattern:
>>
>> elv_iosched_store+0x149/0x180
>> elevator_change+0xdb/0x180
>> elevator_change_done+0x4a/0x1f0
>> blk_mq_free_sched_tags+0x34/0x70
>> blk_mq_free_tags+0x4b/0x60
>> kfree+0x334/0x3b0  <-- crash here
>>
>> === Bisection Results ===
>>
>> I bisected the issue to this commit:
>>
>> commit f5a6604f7a4405450e4a1f54e5430f47290c500f
> 
> It should be solved by the following commit:
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux-block.git/commit/?h=for-6.18/block&id=ba28afbd9eff2a6370f23ef4e6a036ab0cfda409
> 
> Thanks,
> 
Oh, I hadn’t noticed this message before sending my previous email.
It’s quite possible that this could address the observed symptom, though 
I didn’t see any traces of nr_request being modified in the provided 
dmesg.txt. Nonetheless, this change could be a potential fix and may be
worth trying out in a custom kernel.

Thanks,
--Nilay