linux-kernel - Re: CVE-2025-40146: blk-mq: fix potential deadlock while nr

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <813a7d60-6211-4048-9267-ec4bd4a75f73@linux.ibm.com>
Date: Fri, 28 Nov 2025 10:50:47 +0530
From: Nilay Shroff <nilay@...ux.ibm.com>
To: Zheng Qixing <zhengqixing@...weicloud.com>,
        Greg KH <gregkh@...uxfoundation.org>
Cc: cve@...nel.org, linux-kernel@...r.kernel.org, yukuai@...as.com,
        ming.lei@...hat.com, "zhangyi (F)" <yi.zhang@...wei.com>,
        yangerkun <yangerkun@...wei.com>, Hou Tao <houtao1@...wei.com>
Subject: Re: CVE-2025-40146: blk-mq: fix potential deadlock while nr_requests
 grown

On 11/28/25 6:45 AM, Zheng Qixing wrote:
> 
> 在 2025/11/27 21:39, Greg KH 写道:
>> On Thu, Nov 27, 2025 at 09:22:42PM +0800, Zheng Qixing wrote:
>>> Hi,
>>>
>>> Commit b86433721f46 ("blk-mq: fix potential deadlock while nr_requests
>>> grown")  aims to avoid a deadlock issue when the queue is frozen and memory
>>> reclaim is triggered.
>>>
>>> However, the sysfs nr_requests update path is already under a
>>> memalloc_noio_save() region while the queue is frozen (via
>>> blk_mq_freeze_queue()).
>> Did the lockdep splat in
>> https://lore.kernel.org/all/0659ea8d-a463-47c8-9180-43c719e106eb@linux.ibm.com/
>> not describe the issue here that the commit is attempting to solve?
>>
>> thanks,
>>
>> greg k-h
> 
> 
> The deadlock issue described in this link is about elevator switch path, but the patch modifies sysfs nr_requests update path.
> 
> I didn't identify any potential deadlock issues on this path. If I misunderstood something, could someone help clarify?
> 
> 
Let me clarify the confusion here.

The deadlock reported in [1] requires updates across multiple code paths. There are
three distinct paths that need to be fixed to avoid the deadlock. While the report
in [1] only exposed the issue in one of these paths, we already knew that all three
paths needed changes to fully resolve the problem:

1. Elevator change path (via sysfs attribute) that triggers a scheduler tags update
2. Elevator change path triggered by an nr_hw_queues update which also triggers a
   scheduler tags update
3. Scheduler tags update triggered through the nr_requests sysfs attribute (please 
   note when nr_requests grows beyond current queue depth it triggers scheduler
   tags update)

The first two code paths were addressed by:
commit f5a6604f7a44 (“block: fix lockdep warning caused by lock dependency in 
elv_iosched_store”), and commit 04225d13aef1 (“block: fix potential deadlock while
running nr_hw_queue update”) respectively.

The third code path was fixed by:
commit b86433721f46 (“blk-mq: fix potential deadlock while nr_requests grown”).

Ideally, all of these commits should be referenced as collectively fixing the lockdep
splat reported in [1]. I hope this clarifies the situation. Please let me know if you
have any further questions.

[1] https://lore.kernel.org/all/0659ea8d-a463-47c8-9180-43c719e106eb@linux.ibm.com/

Thanks,
--Nilay