Re: [OE-core][PATCH v3 8/9] cve-exclusions: set status for CVE-2023-6238

[Paul Barker <paul@pbarker.dev>]

On Wed, 2026-08-12 at 02:28 -0500, Junjie Cao wrote:
> NVME_IOCTL_IO_CMD and the io_uring passthrough path accept a
> metadata length from userspace without checking it 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.
> 
> Kanchan Joshi posted a stopgap removing unprivileged passthrough,
> reviewed by Christoph Hellwig and applied for nvme-6.6:
> 
>   https://lore.kernel.org/linux-nvme/20231016060519.231880-1-joshi.k@samsung.com/
> 
> It was then backed out. Keith Busch wrote "I believe this large change
> is a bit too late for 6.6 ... It's backed out now", to which Christoph
> Hellwig replied "We leave an exploitable hole in, so I don't think
> waiting any longer is an option". No replacement has been merged: the
> commits the patch would have reverted are all still present, and
> nvme_map_user_request() still passes the user-supplied metadata length
> straight to blk_rq_integrity_map_user() with no cross-check.
> 
> The exposure was introduced by
> 855b7717f44b ("nvme: fine-granular CAP_SYS_ADMIN for nvme io commands")
> in v6.2, so branches carrying older kernels are not affected. Debian
> reached the same conclusion independently, marking the older suites
> "Vulnerable code not present":
> 
>   https://security-tracker.debian.org/tracker/CVE-2023-6238
> 
> Red Hat rates it Low because the device node is root-only by default:
> 
>   https://access.redhat.com/security/cve/CVE-2023-6238

The explanation is confusing here as it misses what actually introduced
a vulnerability. NVME_IOCTL_IO_CMD has always passed through metadata
length without validation. Commit 855b7717f44b allowed less privileged
users to issue NVME_IOCTL_IO_CMD if they have write access to the nvme
device node.

We don't need to recount the story of the patch being applied to the
nvme tree then backed out. It never landed in mainline, that's what
matters.

> 
> CC: Paul Barker <paul@pbarker.dev>
> AI-Generated: Uses Claude (claude-opus-5)
> Signed-off-by: Junjie Cao <junjie.cao@linux.dev>
> ---
> v3: no functional change since v2
> 
> v2: https://lore.kernel.org/openembedded-core/20260803084827.1348810-1-junjie.cao@linux.dev/
> 
>  meta/recipes-kernel/linux/cve-exclusion.inc | 8 ++++++++
>  1 file changed, 8 insertions(+)
> 
> diff --git a/meta/recipes-kernel/linux/cve-exclusion.inc b/meta/recipes-kernel/linux/cve-exclusion.inc
> index c4a9dea..35e0a66 100644
> --- a/meta/recipes-kernel/linux/cve-exclusion.inc
> +++ b/meta/recipes-kernel/linux/cve-exclusion.inc
> @@ -244,3 +244,11 @@ treated as a defence against local attackers"
>  # https://syzkaller.appspot.com/bug?extid=ea7ed3bb2f444cb4dfeb
>  CVE_STATUS[CVE-2023-3397] = "unpatched: no upstream fix merged, the \
>  affected fs/jfs txEnd()/lmLogClose() unmount race is unchanged"
> +
> +# The user metadata length is not checked against the length the device
> +# derives from the command. The fix was applied to nvme-6.6 and then backed
> +# out; nothing has landed since. Kernels before v6.2 predate unprivileged
> +# passthrough (855b7717f44b) and are not affected.
> +# https://lore.kernel.org/linux-nvme/20231016060519.231880-1-joshi.k@samsung.com/
> +CVE_STATUS[CVE-2023-6238] = "unpatched: the proposed fix was applied to \
> +nvme-6.6 and then reverted, no upstream fix has landed since"

Recommended wording, links and include triage date:

    # Triaged August 2026 - Issue was introducted 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 withdrawn"

Best regards,

-- 
Paul Barker