public inbox for linux-nvme@lists.infradead.org
 help / color / mirror / Atom feed
From: AlanCui4080 <me@alancui.cc>
To: Keith Busch <kbusch@kernel.org>
Cc: linux-nvme@lists.infradead.org
Subject: Re: Non-SGL transport mode warnings are set to dev_warn_once will cause confusion
Date: Thu, 09 Apr 2026 23:49:51 +0800	[thread overview]
Message-ID: <1951542.TLkxdtWsSY@alanarchdesktop> (raw)
In-Reply-To: <ade5iAP4y94z0JDL@kbusch-mbp>

On Thursday, 9 April 2026 22:36,you wrote:
> Fine with me. The warning was added in response to people filing CVE's
> against the driver as a sort of acknowledgement that yeah, this
> interface can't validate transfer lengths under these conditions, so
> we're trusting the user isn't abusing it. A sort of nudge that perhaps
> controller vendors might consider supporting the safer option.

Yes, in my opnion, the device node can be only access with privilege by 
default. Change the premission of /dev/nvmexxx to 0666 is as dangerous as 
change /etc/shadow to 0666. So, that's nothing really to worry, every device 
on PCI-E that can DMA will able to corrupt the kernel unless IOMMU is used.

And as what i saw, the https://lore.kernel.org/linux-nvme/
20231013051458.39987-1-joshi.k@samsung.com/T/
#m2a5f9fe3a53322ab67c1dd40d5a448405308ea4b fixed this problem and make it's 
safe even the user changed the premission to 0666.

> Anyway, it's fine with me to move the message and make it less scary.
> How about this:
> 
> ---
> diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c
> index b42d8768d2979..b6aec0e3fbfb8 100644
> --- a/drivers/nvme/host/core.c
> +++ b/drivers/nvme/host/core.c
> @@ -3744,6 +3744,10 @@ int nvme_init_ctrl_finish(struct nvme_ctrl *ctrl,
> bool was_suspended) ret = nvme_hwmon_init(ctrl);
>  		if (ret == -EINTR)
>  			return ret;
> +
> +		if (!nvme_ctrl_sgl_supported(ctrl))
> +			dev_info(ctrl->device,
> +				"passthrough uses implicit buffer 
lengths\n");
>  	}
> 
>  	clear_bit(NVME_CTRL_DIRTY_CAPABILITY, &ctrl->flags);
> --

Since it was a response to a CVE, and if, as I mentioned above, there are 
already patches to prevent unprivileged users from corrupting the kernel, then 
downgrading it to informational might be reasonable? In fact, the CVE rating 
was downgraded once after this vulnerability was submitted, due to the 
difficulty of exploiting it.

What about saying "passthrough uses implicit and unchecked buffer lengths for 
privilege user" which may be more descriptive, and add comment which refers to 
the CVE number like:
```
		/* See CVE-2023-6238, malformed commands from root users 
can overflow the buffer and corrupt the kernel */
		if (!nvme_ctrl_sgl_supported(ctrl))
			dev_info(ctrl->device,
				"passthrough uses implicit and 
unchecked buffer lengths for privilege user");
```

I recently started back using a Linux desktop again, and this is at least my 
first time using Linux with NVMe drives. I feel that nvme module is a bit too 
sensitive, even becoming a major source of warnings in my dmesg, including not 
only this one, but also "missing or invalid SUBNQN field." And as https://
lwn.net/Articles/876209/, A warning indicates that the kernel cannot handle a 
certain situation and is running in a degraded manner based on certain 
assumptions, which may lead to unexpected situations.I believe that a good 
system administrator should review and ensure that each kernel warnings are 
either negligible or an action has been taken to eliminate them. :)

Alan.






      reply	other threads:[~2026-04-09 15:50 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-09  8:46 Non-SGL transport mode warnings are set to dev_warn_once will cause confusion AlanCui4080
2026-04-09 14:36 ` Keith Busch
2026-04-09 15:49   ` AlanCui4080 [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=1951542.TLkxdtWsSY@alanarchdesktop \
    --to=me@alancui.cc \
    --cc=kbusch@kernel.org \
    --cc=linux-nvme@lists.infradead.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox