All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] nvmet: fix the CSTS state iteration in debugfs
@ 2026-11-14 17:28 shao.mingyin
  2026-11-14 17:32 ` sashiko-bot
  0 siblings, 1 reply; 2+ messages in thread
From: shao.mingyin @ 2026-11-14 17:28 UTC (permalink / raw)
  To: kbusch, axboe, hch, sagi, linux-nvme; +Cc: linux-kernel, stable

From: Shao Mingyin <shao.mingyin@zte.com.cn>

nvmet_ctrl_state_show() uses the size of a sparse name array as a
bit count.  Its last index is NVME_CSTS_PP (BIT(5)), so the loop has
33 iterations and evaluates BIT(32).  This exceeds the width of an
unsigned long on 32-bit systems.  With GCC on x86 this can make a
normal ready status print "ready|ready".

Iterate over the 32 bits of csts instead.  Check the name array bounds
before indexing it and print unknown bits as unsigned values.  The
out-of-bounds lookup requires a reserved status bit; the current target
code does not set those bits.

Fixes: 107a23185d99 ("objtool, nvmet: Fix out-of-bounds stack access in nvmet_ctrl_state_show()")
Cc: stable@vger.kernel.org
Signed-off-by: Shao Mingyin <shao.mingyin@zte.com.cn>
---
Tested on 7.3.0-next-20261030 (QEMU/TCG guest, KASAN) with the loop
transport.  No in-tree path sets a reserved csts bit, so the guest
injects one through a test-only debugfs attribute added for this test
(not part of the patch).

ORing BIT(31) and then BIT(6) into ctrl->csts and reading the controller
state attribute:

  unpatched                            patched
  BUG: unable to handle page fault     csts_bit31='ready|2147483648'
  RIP: nvmet_ctrl_state_show+0x90      csts_bit6='ready|64|2147483648'
  Kernel panic - not syncing

 drivers/nvme/target/debugfs.c |    9 +++++----
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/nvme/target/debugfs.c b/drivers/nvme/target/debugfs.c
index e85fe1d4c9f8..905a08c63669 100644
--- a/drivers/nvme/target/debugfs.c
+++ b/drivers/nvme/target/debugfs.c
@@ -78,18 +78,19 @@ static int nvmet_ctrl_state_show(struct seq_file *m, void *p)
 	bool sep = false;
 	int i;
 
-	for (i = 0; i < ARRAY_SIZE(csts_state_names); i++) {
-		int state = BIT(i);
+	for (i = 0; i < BITS_PER_TYPE(u32); i++) {
+		u32 state = BIT(i);
 
 		if (!(ctrl->csts & state))
 			continue;
 		if (sep)
 			seq_puts(m, "|");
 		sep = true;
-		if (csts_state_names[state])
+		if (state < ARRAY_SIZE(csts_state_names) &&
+		    csts_state_names[state])
 			seq_puts(m, csts_state_names[state]);
 		else
-			seq_printf(m, "%d", state);
+			seq_printf(m, "%u", state);
 	}
 	if (sep)
 		seq_printf(m, "\n");
-- 
2.43.0

^ permalink raw reply related	[flat|nested] 2+ messages in thread

* Re: [PATCH] nvmet: fix the CSTS state iteration in debugfs
  2026-11-14 17:28 [PATCH] nvmet: fix the CSTS state iteration in debugfs shao.mingyin
@ 2026-11-14 17:32 ` sashiko-bot
  0 siblings, 0 replies; 2+ messages in thread
From: sashiko-bot @ 2026-11-14 17:32 UTC (permalink / raw)
  To: shao.mingyin, linux-nvme

Thank you for your contribution! Sashiko AI review found no new issues
in this patch, but noticed 1 related pre-existing issue it does not
introduce:
- [Medium] nvmet: data race in nvmet_ctrl_kato_show() [1]
--

commit 7730565aae4019e36ef00daab9fa6f3d654b6597
Author: Shao Mingyin <shao.mingyin@zte.com.cn>

nvmet: fix the CSTS state iteration in debugfs

This commit fixes nvmet_ctrl_state_show() to iterate over the 32 bits of
csts instead of the size of csts_state_names[], checking array bounds and
printing unknown bits as unsigned values.

> diff --git a/drivers/nvme/target/debugfs.c b/drivers/nvme/target/debugfs.c
> index e85fe1d4c9f8d..905a08c63669e 100644
> --- a/drivers/nvme/target/debugfs.c
> +++ b/drivers/nvme/target/debugfs.c
> @@ -78,18 +78,19 @@ static int nvmet_ctrl_state_show(struct seq_file *m, void *p)
>  	bool sep = false;
>  	int i;
>  
> -	for (i = 0; i < ARRAY_SIZE(csts_state_names); i++) {
> -		int state = BIT(i);
> +	for (i = 0; i < BITS_PER_TYPE(u32); i++) {
> +		u32 state = BIT(i);
>  
>  		if (!(ctrl->csts & state))
>  			continue;

[Severity: Medium]
This problem wasn't introduced by this patch, but can reading ctrl->csts
across loop iterations in nvmet_ctrl_state_show() (as well as ctrl->kato
in nvmet_ctrl_kato_show()) without synchronization or READ_ONCE() cause a
data race [1] when administrative commands or state transitions
concurrently update the controller state, resulting in inconsistent or
torn debugfs output?

[1] https://sashiko.dev/#/bug/linux-2b037cd9-c44c-44de-95f8-41de5f514a0b

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261115012806699yIujDZo6TywlxuhhSIktO@zte.com.cn?part=1


^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2026-11-14 17:33 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-11-14 17:28 [PATCH] nvmet: fix the CSTS state iteration in debugfs shao.mingyin
2026-11-14 17:32 ` sashiko-bot

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.