All of lore.kernel.org
 help / color / mirror / Atom feed
From: Krystian Kaniewski <krystianmkaniewski@gmail.com>
To: syzbot <syzbot@kernel.org>,
	syzkaller-upstream-moderation@googlegroups.com
Cc: syzbot@lists.linux.dev
Subject: Re: [PATCH RFC] blk-mq: fix out-of-bounds read in blk_mq_free_rqs
Date: Thu, 10 Sep 2026 12:17:06 +0200	[thread overview]
Message-ID: <6ed0fc4e-838c-42bc-a30f-c5fa1102af1e@gmail.com> (raw)
In-Reply-To: <80f75813-8fe4-4698-8424-5faaa6bbf6da@mail.kernel.org>

#syz upstream

On 8/7/2026 9:40 AM, syzbot wrote:
> A KASAN slab-out-of-bounds read can occur in blk_mq_free_rqs() when there
> is a mismatch between the number of hardware queues allocated for the IO
> scheduler (et->nr_hw_queues) and the number of hardware queues in the block
> tag set (set->nr_hw_queues).
>
> This mismatch can happen if blk_mq_update_nr_hw_queues() fails halfway
> through (e.g., due to memory pressure during
> blk_mq_prealloc_tag_set_tags()). In this error path, the elevator is
> restored with a larger number of hardware queues than the block tag set
> actually has.
>
> When the elevator is later freed, blk_mq_free_sched_tags() iterates up to
> the new et->nr_hw_queues and calls blk_mq_free_rqs(). In blk_mq_free_rqs(),
> it attempts to access set->tags[hctx_idx] to get the driver tags. Because
> set->nr_hw_queues was not updated due to the earlier failure, set->tags
> still has the old (smaller) size, leading to an out-of-bounds read.
>
> BUG: KASAN: slab-out-of-bounds in blk_mq_free_rqs+0xde/0x680
> Read of size 8 at addr ffff88818d67fc28 by task syz-executor117/5839
> Call Trace:
>   blk_mq_free_rqs+0xde/0x680
>   blk_mq_free_map_and_rqs+0x40/0xf0
>   blk_mq_free_sched_tags
>   blk_mq_free_sched_res+0xeb/0x280
>   elevator_change_done+0x1d2/0x5c0
>   elevator_change+0x34f/0x480
>   elv_iosched_store+0x504/0x630
>   queue_attr_store+0x207/0x2b0
>
> To fix this, explicitly check if hctx_idx < set->nr_hw_queues before
> accessing set->tags[hctx_idx]. If hctx_idx >= set->nr_hw_queues, the
> hardware queue doesn't exist in the tag set, meaning there are no driver
> tags to clear mappings from. In this case, safely set drv_tags to NULL. The
> subsequent call to blk_mq_clear_rq_mapping() already handles a NULL
> drv_tags pointer and will safely return.
>
> This fix also prevents a similar out-of-bounds read in the failure path of
> blk_mq_alloc_rqs(), where a failure during new driver tag allocation could
> lead to blk_mq_free_rqs() being called with an hctx_idx greater than or
> equal to set->nr_hw_queues.
>
> Fixes: 04225d13aef1 ("block: fix potential deadlock while running nr_hw_queue update")
> Assisted-by: Gemini:gemini-3.5-flash Gemini:gemini-3.1-pro-preview syzbot
> Reported-by: syzbot+e90526cab23b9efcd03c@syzkaller.appspotmail.com
> Closes: https://syzkaller.appspot.com/bug?extid=e90526cab23b9efcd03c
> Link: https://syzkaller.appspot.com/ai_job?id=827b5760-86a0-4f44-9c69-430b572eac12
> To: "Jens Axboe" <axboe@kernel.dk>
> To: <linux-block@vger.kernel.org>
> To: "Nilay Shroff" <nilay@linux.ibm.com>
> Cc: <linux-kernel@vger.kernel.org>
>
> ---
> diff --git a/block/blk-mq.c b/block/blk-mq.c
> index 2c850330a..8e6726b37 100644
> --- a/block/blk-mq.c
> +++ b/block/blk-mq.c
> @@ -3473,8 +3473,10 @@ void blk_mq_free_rqs(struct blk_mq_tag_set *set, struct blk_mq_tags *tags,
>   
>   	if (blk_mq_is_shared_tags(set->flags))
>   		drv_tags = set->shared_tags;
> -	else
> +	else if (hctx_idx < set->nr_hw_queues)
>   		drv_tags = set->tags[hctx_idx];
> +	else
> +		drv_tags = NULL;
>   
>   	if (tags->static_rqs && set->ops->exit_request) {
>   		int i;
>
>
> base-commit: 075b74841bd0065a3bda3440873c747938e69b68

      reply	other threads:[~2026-09-10 10:17 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-07  7:40 [PATCH RFC] blk-mq: fix out-of-bounds read in blk_mq_free_rqs syzbot
2026-09-10 10:17 ` Krystian Kaniewski [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=6ed0fc4e-838c-42bc-a30f-c5fa1102af1e@gmail.com \
    --to=krystianmkaniewski@gmail.com \
    --cc=syzbot@kernel.org \
    --cc=syzbot@lists.linux.dev \
    --cc=syzkaller-upstream-moderation@googlegroups.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.