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: <9ef3f966-c9bc-2da0-3fbf-a926eee740c9@huawei.com>
Date: Fri, 28 Nov 2025 14:33:36 +0800
From: yangerkun <yangerkun@...wei.com>
To: Nilay Shroff <nilay@...ux.ibm.com>, 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>, Hou Tao
	<houtao1@...wei.com>
Subject: Re: CVE-2025-40146: blk-mq: fix potential deadlock while nr_requests
 grown



在 2025/11/28 13:20, Nilay Shroff 写道:
> 
> 
> 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)

commit b86433721f46d934940528f28d49c1dedb690df1 (HEAD -> master)
Author: Yu Kuai <yukuai3@...wei.com>
Date:   Wed Sep 10 16:04:43 2025 +0800

     blk-mq: fix potential deadlock while nr_requests grown

     Allocate and free sched_tags while queue is freezed can deadlock[1],
     this is a long term problem, hence allocate memory before freezing
     queue and free memory after queue is unfreezed.

     [1] 
https://lore.kernel.org/all/0659ea8d-a463-47c8-9180-43c719e106eb@linux.ibm.com/
     Fixes: e3a2b3f931f5 ("blk-mq: allow changing of queue depth through 
sysfs")

     Signed-off-by: Yu Kuai <yukuai3@...wei.com>
     Reviewed-by: Nilay Shroff <nilay@...ux.ibm.com>
     Signed-off-by: Jens Axboe <axboe@...nel.dk>

We are assume that what's the problem Yu describe is when we update
nr_request, we may need some memory allocation(nr_requests grows). And
the memory allocation may trigger some memory reclaim, and fall into
another I/O process, and since the request_queue has been freezen, there
exist deadlock.

But after checking the source code, there exist
queue_requests_store->blk_mq_freeze_queue->memalloc_noio_save, the
whole process which may trigger memory allocation won't trigger I/O
process. So deadlock can not happened... And if that's true, this patch
does not fix any problem.

Thanks,
Erkun.

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