All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junjie Cao <junjie.cao@linux.dev>
To: openembedded-core@lists.openembedded.org
Cc: paul@pbarker.dev
Subject: [OE-core][PATCH v4 7/8] cve-exclusions: set status for CVE-2023-6238
Date: Sun, 23 Aug 2026 23:21:22 -0500	[thread overview]
Message-ID: <20260824042123.1456876-8-junjie.cao@linux.dev> (raw)
In-Reply-To: <20260824042123.1456876-1-junjie.cao@linux.dev>

NVME_IOCTL_IO_CMD and the io_uring passthrough path have never checked
the user-supplied metadata length against the number of blocks and the
namespace metadata size that the device uses to size the transfer, so
the device can DMA past the end of the buffer. 855b7717f44b ("nvme:
fine-granular CAP_SYS_ADMIN for nvme io commands", v6.2) let users with
write access to the device node issue the ioctl, turning the missing
check into an exposure; kernels before v6.2 are not affected, as Debian
concluded independently:

  https://security-tracker.debian.org/tracker/CVE-2023-6238

A fix removing unprivileged passthrough was proposed but not merged to
mainline, and nvme_map_user_request() still passes the metadata length
to blk_rq_integrity_map_user() with no cross-check:

  https://lore.kernel.org/linux-nvme/20231016060519.231880-1-joshi.k@samsung.com/

CC: Paul Barker <paul@pbarker.dev>
AI-Generated: Uses Claude (claude-opus-5)
Signed-off-by: Junjie Cao <junjie.cao@linux.dev>
---
v4:
- rework the explanation around 855b7717f44b making the ioctl reachable,
  per review; drop the applied-then-backed-out narrative
- status reads "Proposed fix was not merged" rather than "withdrawn",
  as flagged on the v3 thread: the fix was backed out by the nvme
  maintainer, not withdrawn by its author

v3: https://lore.kernel.org/openembedded-core/20260812072842.1176341-1-junjie.cao@linux.dev/

 meta/recipes-kernel/linux/cve-exclusion.inc | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/meta/recipes-kernel/linux/cve-exclusion.inc b/meta/recipes-kernel/linux/cve-exclusion.inc
index a133bf08..4729191a 100644
--- a/meta/recipes-kernel/linux/cve-exclusion.inc
+++ b/meta/recipes-kernel/linux/cve-exclusion.inc
@@ -240,3 +240,13 @@ CVE_STATUS[CVE-2022-4543] = "unpatched: No fix has been proposed"
 # https://security-tracker.debian.org/tracker/CVE-2023-3397
 # https://ubuntu.com/security/CVE-2023-3397
 CVE_STATUS[CVE-2023-3397] = "unpatched: Proposed fix was withdrawn"
+
+# Triaged August 2026 - Issue was introduced by kernel commit 855b7717f44b
+# ("nvme: fine-granular CAP_SYS_ADMIN for nvme io commands") in Linux v6.2.
+# Linux 6.1 and earlier not affected. Unfixed in recent Debian/Ubuntu releases
+# which use affected kernels. There was a fix proposed, but it was not merged
+# to mainline.
+# https://security-tracker.debian.org/tracker/CVE-2023-6238
+# https://ubuntu.com/security/CVE-2023-6238
+# https://lore.kernel.org/linux-nvme/20231016060519.231880-1-joshi.k@samsung.com/
+CVE_STATUS[CVE-2023-6238] = "unpatched: Proposed fix was not merged"
-- 
2.43.0



  parent reply	other threads:[~2026-08-24  2:23 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-24  4:21 [OE-core][PATCH v4 0/8] cve-exclusions: triage eight kernel CVEs lacking upstream fix data Junjie Cao
2026-08-24  4:21 ` [OE-core][PATCH v4 1/8] cve-exclusions: set status for CVE-2019-14899 Junjie Cao
2026-08-24  4:21 ` [OE-core][PATCH v4 2/8] cve-exclusions: set status for CVE-2021-3714 Junjie Cao
2026-08-24  4:21 ` [OE-core][PATCH v4 3/8] cve-exclusions: set status for CVE-2021-3864 Junjie Cao
2026-08-24  4:21 ` [OE-core][PATCH v4 4/8] cve-exclusions: set status for CVE-2022-1247 Junjie Cao
2026-08-24  4:21 ` [OE-core][PATCH v4 5/8] cve-exclusions: set status for CVE-2022-4543 Junjie Cao
2026-08-24  4:21 ` [OE-core][PATCH v4 6/8] cve-exclusions: set status for CVE-2023-3397 Junjie Cao
2026-08-24  4:21 ` Junjie Cao [this message]
2026-08-24  4:21 ` [OE-core][PATCH v4 8/8] cve-exclusions: set status for CVE-2023-6240 Junjie Cao
2026-08-24  7:57 ` [OE-core][PATCH v4 0/8] cve-exclusions: triage eight kernel CVEs lacking upstream fix data Paul Barker

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=20260824042123.1456876-8-junjie.cao@linux.dev \
    --to=junjie.cao@linux.dev \
    --cc=openembedded-core@lists.openembedded.org \
    --cc=paul@pbarker.dev \
    /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.