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.
prev parent 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