From: Sasha Levin <sashal@kernel.org>
To: stable@vger.kernel.org
Cc: Yu Zhang <yuz08559@gmail.com>,
Maurizio Lombardi <mlombard@redhat.com>,
Keith Busch <kbusch@kernel.org>, Sasha Levin <sashal@kernel.org>
Subject: [PATCH 6.1.y 2/2] nvmet: take subsys->lock while force-reconnecting in nvmet_subsys_attr_qid_max_store()
Date: Wed, 11 Nov 2026 12:26:08 -0500 [thread overview]
Message-ID: <20261111172541.3562889-2-sashal@kernel.org> (raw)
In-Reply-To: <20261111172541.3562889-1-sashal@kernel.org>
From: Yu Zhang <yuz08559@gmail.com>
[ Upstream commit 9f426f14051181e251590783e68ce589a63e2b1c ]
nvmet_subsys_attr_qid_max_store() sets subsys->max_qid and then walks
subsys->ctrls to force every controller to reconnect, but it holds only
nvmet_config_sem (for write). subsys->ctrls is protected by subsys->lock:
nvmet_alloc_ctrl() adds an entry under subsys->lock, and nvmet_ctrl_free()
removes it under subsys->lock with list_del() + kfree() (not kfree_rcu).
The free path takes no nvmet_config_sem, so the two locks are independent.
A controller teardown (host disconnect, keep-alive timeout or fatal error
-> nvmet_sq_destroy() -> nvmet_ctrl_put() -> nvmet_ctrl_free()) can
therefore list_del() an entry while qid_max_store() is iterating the list,
corrupting the walk.
KASAN, concurrent "echo 128 > .../subsystems/<nqn>/attr_qid_max" racing
nvme-loop controllers connecting and disconnecting, panics in seconds:
BUG: KASAN: null-ptr-deref in nvmet_subsys_attr_qid_max_store+0x10d/0x1b0
Read of size 8 at addr 0000000000000090
Call Trace:
nvmet_subsys_attr_qid_max_store+0x10d/0x1b0
configfs_write_iter+0x1a7/0x250
vfs_write+0x5df/0x940
ksys_write+0xfd/0x1e0
(also seen as a general-protection fault dereferencing a LIST_POISON
pointer at the same instruction.)
Take subsys->lock around the list_for_each_entry() loop, matching every
other subsys->ctrls accessor. ->delete_ctrl() only queues asynchronous
controller teardown, so it does not re-enter subsys->lock under the loop.
Fixes: 3e980f5995e0 ("nvmet: expose max queues to configfs")
Cc: stable@vger.kernel.org
Reviewed-by: Maurizio Lombardi <mlombard@redhat.com>
Signed-off-by: Yu Zhang <yuz08559@gmail.com>
Tested-by: Yu Zhang <yuz08559@gmail.com>
Signed-off-by: Keith Busch <kbusch@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/nvme/target/configfs.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/nvme/target/configfs.c b/drivers/nvme/target/configfs.c
index 8c12de188e992..cbc3693d5fc0a 100644
--- a/drivers/nvme/target/configfs.c
+++ b/drivers/nvme/target/configfs.c
@@ -1332,8 +1332,10 @@ static ssize_t nvmet_subsys_attr_qid_max_store(struct config_item *item,
subsys->max_qid = qid_max;
/* Force reconnect */
+ mutex_lock(&subsys->lock);
list_for_each_entry(ctrl, &subsys->ctrls, subsys_entry)
ctrl->ops->delete_ctrl(ctrl);
+ mutex_unlock(&subsys->lock);
up_write(&nvmet_config_sem);
return cnt;
--
2.53.0
prev parent reply other threads:[~2026-11-11 17:26 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-07 10:53 FAILED: patch "[PATCH] nvmet: take subsys->lock while force-reconnecting in nvmet_subsys_attr_qid_max_store()" failed to apply to 6.1-stable tree Sasha Levin
2026-11-11 17:26 ` [PATCH 6.1.y 1/2] nvmet: force reconnect when number of queue changes Sasha Levin
2026-11-11 17:26 ` Sasha Levin [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=20261111172541.3562889-2-sashal@kernel.org \
--to=sashal@kernel.org \
--cc=kbusch@kernel.org \
--cc=mlombard@redhat.com \
--cc=stable@vger.kernel.org \
--cc=yuz08559@gmail.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.