[OE-core][PATCH v4 0/8] cve-exclusions: triage eight kernel CVEs lacking upstream fix data

[OE-core][PATCH v4 0/8] cve-exclusions: triage eight kernel CVEs lacking upstream fix data

[Junjie Cao]

This is v4 of the kernel CVE triage from Paul Barker's "linux-yocto
CVEs in need of triage" request, reworked according to his review of
v3 [1].

Changes since v3:

- Seven entries adopt the comment and CVE_STATUS wordings suggested in
  [1], including triage dates and distribution tracker links in the
  .inc comments; the CVE-2022-1247 entry was approved as-is and is
  unchanged. Commit message detail flagged as unnecessary or
  time-consuming to validate is dropped. One deviation: the
  CVE-2023-6238 status reads "Proposed fix was not merged" rather than
  "withdrawn" - the fix was backed out by the nvme maintainer, not
  withdrawn by its author - matching the comment above the entry.

- CVE-2022-0400 stays out of this series as agreed. Red Hat PSIRT has
  since answered the request for details (ticket PSIRTSUPT-22046) and
  named the affected code; it is the issue fixed in v6.13 that
  upstream tracks as CVE-2024-49568, with the details recorded on the
  public bug [2]. A separate patch records the fixed-version status.

Summary of the eight verdicts:

  fixed-version   CVE-2022-1247   6.17, rose_neigh refcount conversion
  unpatched       CVE-2019-14899  weak host model, no upstream fix
                  CVE-2021-3714   inherent to KSM deduplication
                  CVE-2021-3864   proposed fixes not merged
                  CVE-2022-4543   EntryBleed, no fix proposed
                  CVE-2023-3397   JFS UAF, proposed fix withdrawn
                  CVE-2023-6238   NVMe passthrough, fix not merged
                  CVE-2023-6240   Marvin oracle, fixed only in RHEL

AI assistance is disclosed with the AI-Generated trailer on each patch.

Once these are settled I can prepare the wrynose and scarthgap
backports.

[1] https://lore.kernel.org/openembedded-core/7b18fd3a5e6b660b9c605671da2b188b5abbf4ba.camel@pbarker.dev/
[2] https://bugzilla.redhat.com/show_bug.cgi?id=2044575

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

Junjie Cao (8):
  cve-exclusions: set status for CVE-2019-14899
  cve-exclusions: set status for CVE-2021-3714
  cve-exclusions: set status for CVE-2021-3864
  cve-exclusions: set status for CVE-2022-1247
  cve-exclusions: set status for CVE-2022-4543
  cve-exclusions: set status for CVE-2023-3397
  cve-exclusions: set status for CVE-2023-6238
  cve-exclusions: set status for CVE-2023-6240

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

-- 
2.43.0

[OE-core][PATCH v4 1/8] cve-exclusions: set status for CVE-2019-14899

[Junjie Cao]

A network-adjacent attacker can send packets addressed to a host's VPN
tunnel address over the physical interface. Because Linux uses the weak
host model by default, the host replies, which lets the attacker infer
the tunnel address, confirm active connections and eventually inject
into the tunneled TCP stream.

No upstream kernel fix exists. Ubuntu has the fix deferred since
2019-12-13, Debian does not track it against the kernel, and Red Hat
scopes it to openvpn:

  https://ubuntu.com/security/CVE-2019-14899
  https://security-tracker.debian.org/tracker/CVE-2019-14899

Record it unpatched so it stays visible rather than excluded.

CC: Paul Barker <paul@pbarker.dev>
AI-Generated: Uses Claude (claude-opus-5)
Signed-off-by: Junjie Cao <junjie.cao@linux.dev>
---
v4:
- use the review's comment and status wording; drop the mitigation
  discussion

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

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

diff --git a/meta/recipes-kernel/linux/cve-exclusion.inc b/meta/recipes-kernel/linux/cve-exclusion.inc
index d27d7644..b2eb15d0 100644
--- a/meta/recipes-kernel/linux/cve-exclusion.inc
+++ b/meta/recipes-kernel/linux/cve-exclusion.inc
@@ -192,3 +192,8 @@ CVE_STATUS[CVE-2025-68195] = "fixed-version: Fixed from 6.18"
 # Fix https://git.kernel.org/stable/c/b4b64fda4d30a83a7f00e92a0c8a1d47699609f3
 # Backport https://git.kernel.org/stable/c/75c5d9bce072abbbc09b701a49869ac23c34a906
 CVE_STATUS[CVE-2025-71145] = "cpe-stable-backport: Fixed from v6.18.3"
+
+# Triaged August 2026 - no upstream fix, Ubuntu fix deferred
+# https://ubuntu.com/security/CVE-2019-14899
+CVE_STATUS[CVE-2019-14899] = "unpatched: Consequence of the default weak host \
+model, no upstream fix"
-- 
2.43.0

[OE-core][PATCH v4 2/8] cve-exclusions: set status for CVE-2021-3714

[Junjie Cao]

KSM merges identical anonymous pages across processes. An attacker who
can place chosen page-sized content in a victim's memory can detect the
merge through the timing of the resulting copy-on-write fault, and so
leak memory contents.

There is no upstream fix; removing the side channel means removing
deduplication. Distribution trackers describe it the same way - Debian
marks src:linux unfixed with "Inherent design limitation, can be
avoided by not using KSM", Red Hat closed its bug WONTFIX, and Ubuntu
records no upstream fix as of 2024-06-17:

  https://security-tracker.debian.org/tracker/CVE-2021-3714
  https://bugzilla.redhat.com/show_bug.cgi?id=1931327
  https://ubuntu.com/security/CVE-2021-3714

CC: Paul Barker <paul@pbarker.dev>
AI-Generated: Uses Claude (claude-opus-5)
Signed-off-by: Junjie Cao <junjie.cao@linux.dev>
---
v4:
- use the review's comment and status wording; drop the KSM runtime
  opt-in paragraph

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

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

diff --git a/meta/recipes-kernel/linux/cve-exclusion.inc b/meta/recipes-kernel/linux/cve-exclusion.inc
index b2eb15d0..36643ccc 100644
--- a/meta/recipes-kernel/linux/cve-exclusion.inc
+++ b/meta/recipes-kernel/linux/cve-exclusion.inc
@@ -197,3 +197,12 @@ CVE_STATUS[CVE-2025-71145] = "cpe-stable-backport: Fixed from v6.18.3"
 # https://ubuntu.com/security/CVE-2019-14899
 CVE_STATUS[CVE-2019-14899] = "unpatched: Consequence of the default weak host \
 model, no upstream fix"
+
+# Triaged August 2026 - no upstream fix, Debian says "Inherent design
+# limitation, can be avoided by not using KSM", Red Hat closed their bug as
+# WONTFIX.
+# https://security-tracker.debian.org/tracker/CVE-2021-3714
+# https://bugzilla.redhat.com/show_bug.cgi?id=1931327
+# https://ubuntu.com/security/CVE-2021-3714
+CVE_STATUS[CVE-2021-3714] = "unpatched: Timing side channel inherent to Kernel \
+Same-page Merging (KSM) page deduplication"
-- 
2.43.0

[OE-core][PATCH v4 3/8] cve-exclusions: set status for CVE-2021-3864

[Junjie Cao]

begin_new_exec() resets dumpability to owner-dumpable whenever the real
and effective ids match at exec time. A binary exec'd by a setuid
program that has already called setuid(0) therefore becomes dumpable as
root, and with a relative core_pattern plus an attacker-controlled
working directory the resulting core file can be dropped into a
privileged directory such as /etc/logrotate.d.

Full report with proof of concept:

  https://www.openwall.com/lists/oss-security/2021/10/20/2

Two fixes were proposed and neither was merged. Waiman Long's patch
was judged "not a particularly effective mitigation" by Eric W.
Biederman and the discussion went quiet by early 2022; Wander Lairson
Costa's RFC v2 received design feedback and no v3 followed:

  https://lore.kernel.org/all/20211221021744.864115-1-longman@redhat.com/
  https://lore.kernel.org/all/20211228170910.623156-1-wander@redhat.com/

CC: Paul Barker <paul@pbarker.dev>
AI-Generated: Uses Claude (claude-opus-5)
Signed-off-by: Junjie Cao <junjie.cao@linux.dev>
---
v4:
- use the review's comment and status wording; drop the coredump path
  analysis paragraph
- quote Biederman's assessment verbatim

v3: https://lore.kernel.org/openembedded-core/20260812072842.1176341-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 36643ccc..36920e2c 100644
--- a/meta/recipes-kernel/linux/cve-exclusion.inc
+++ b/meta/recipes-kernel/linux/cve-exclusion.inc
@@ -206,3 +206,11 @@ model, no upstream fix"
 # https://ubuntu.com/security/CVE-2021-3714
 CVE_STATUS[CVE-2021-3714] = "unpatched: Timing side channel inherent to Kernel \
 Same-page Merging (KSM) page deduplication"
+
+# Triaged August 2026 - Two fixes proposed upstream but neither was merged,
+# attempts to fix seem to have petered out. Unfixed in Debian/Ubuntu.
+# https://lore.kernel.org/all/20211221021744.864115-1-longman@redhat.com/
+# https://lore.kernel.org/all/20211228170910.623156-1-wander@redhat.com/
+# https://security-tracker.debian.org/tracker/CVE-2021-3864
+# https://ubuntu.com/security/CVE-2021-3864
+CVE_STATUS[CVE-2021-3864] = "unpatched: Proposed fixes were not merged upstream"
-- 
2.43.0

[OE-core][PATCH v4 4/8] cve-exclusions: set status for CVE-2022-1247

[Junjie Cao]

The CVE describes a race between rose_connect() and the code that
frees a rose_neigh once its count and use fields reach zero. The race
in the original report [1] is the one fixed independently in v6.17 by
the rose_neigh refcount conversion:

  https://git.kernel.org/linus/d860d1faa6b2ce3becfdb8b0c2b048ad31800061
  ("net: rose: convert 'use' field to refcount_t", v6.17)
  https://git.kernel.org/linus/da9c9c877597170b929a6121a68dcd3dd9a80f45
  ("net: rose: include node references in rose_neigh refcount", v6.17)

The Linux kernel CVE team assigned these commits CVE-2025-39826 and
CVE-2025-39827.

[1] https://bugzilla.redhat.com/show_bug.cgi?id=2066799

CC: Paul Barker <paul@pbarker.dev>
AI-Generated: Uses Claude (claude-opus-5)
Signed-off-by: Junjie Cao <junjie.cao@linux.dev>
---
v4:
- simplify the explanation as suggested; reference the original report
  instead of arguing from the commit diffs

v3: https://lore.kernel.org/openembedded-core/20260812072842.1176341-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 36920e2c..a9b4d9a2 100644
--- a/meta/recipes-kernel/linux/cve-exclusion.inc
+++ b/meta/recipes-kernel/linux/cve-exclusion.inc
@@ -214,3 +214,11 @@ Same-page Merging (KSM) page deduplication"
 # https://security-tracker.debian.org/tracker/CVE-2021-3864
 # https://ubuntu.com/security/CVE-2021-3864
 CVE_STATUS[CVE-2021-3864] = "unpatched: Proposed fixes were not merged upstream"
+
+# net/rose and rose_connect() were removed entirely in v7.1 (dd8d4bc28ad7).
+# The 6.18 kernel on master still carries net/rose; there the race is
+# closed by the v6.17 refcount conversion, which upstream tracks as
+# CVE-2025-39826 / CVE-2025-39827.
+# Fix https://git.kernel.org/linus/d860d1faa6b2ce3becfdb8b0c2b048ad31800061
+# Fix https://git.kernel.org/linus/da9c9c877597170b929a6121a68dcd3dd9a80f45
+CVE_STATUS[CVE-2022-1247] = "fixed-version: Fixed from version 6.17"
-- 
2.43.0

[OE-core][PATCH v4 5/8] cve-exclusions: set status for CVE-2022-4543

[Junjie Cao]

KPTI clones the kernel entry text into the user page tables at its
KASLR-slid address and, on CPUs with PGE, sets the global bit on those
entries. The translation survives the CR3 write on kernel exit, and a
local attacker can time prefetch instructions across the kernel range
to recover the KASLR base in under a second.

Disclosure and write-up:

  https://www.openwall.com/lists/oss-security/2022/12/16/3
  https://www.willsroot.io/2022/12/entrybleed.html

The disclosure states that after discussion with security@kernel.org
and linux-distros "a fix for this is currently not available", and none
has appeared since; arch/x86/mm/pti.c still clones the entry text and
sets _PAGE_GLOBAL on the cloned mapping. Debian notes "Ignored
upstream and KASLR is not expected to be resistant to local attacks";
Ubuntu has the fix deferred since 2023-01-10:

  https://security-tracker.debian.org/tracker/CVE-2022-4543
  https://ubuntu.com/security/CVE-2022-4543

CC: Paul Barker <paul@pbarker.dev>
AI-Generated: Uses Claude (claude-opus-5)
Signed-off-by: Junjie Cao <junjie.cao@linux.dev>
---
v4:
- use the review's comment and status wording; drop the cpu_entry_area
  commit reference
- tighten the mechanism wording and the timing claim to match the
  cited sources

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

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

diff --git a/meta/recipes-kernel/linux/cve-exclusion.inc b/meta/recipes-kernel/linux/cve-exclusion.inc
index a9b4d9a2..4318fc79 100644
--- a/meta/recipes-kernel/linux/cve-exclusion.inc
+++ b/meta/recipes-kernel/linux/cve-exclusion.inc
@@ -222,3 +222,12 @@ CVE_STATUS[CVE-2021-3864] = "unpatched: Proposed fixes were not merged upstream"
 # Fix https://git.kernel.org/linus/d860d1faa6b2ce3becfdb8b0c2b048ad31800061
 # Fix https://git.kernel.org/linus/da9c9c877597170b929a6121a68dcd3dd9a80f45
 CVE_STATUS[CVE-2022-1247] = "fixed-version: Fixed from version 6.17"
+
+# Triaged August 2026 - "EntryBleed", discussed with the kernel security team
+# but no fix appears to have been published since then. Debian says "Ignored
+# upstream and KASLR is not expected to be resistant to local attacks", fix
+# deferred in Ubuntu.
+# https://www.openwall.com/lists/oss-security/2022/12/16/3
+# https://security-tracker.debian.org/tracker/CVE-2022-4543
+# https://ubuntu.com/security/CVE-2022-4543
+CVE_STATUS[CVE-2022-4543] = "unpatched: No fix has been proposed"
-- 
2.43.0

[OE-core][PATCH v4 6/8] cve-exclusions: set status for CVE-2023-3397

[Junjie Cao]

txEnd() in fs/jfs/jfs_txnmgr.c reads the log pointer from the
superblock info, drops TXN_LOCK and then takes log->gclock, while
lmLogClose() can free that log during umount.

No fix has been merged. The 2023 proposal was withdrawn by its author
("I think my fix method is not a good solution"), and proposals in 2026
for similar jfs slab use-after-free races are unreviewed:

  https://lore.kernel.org/all/20230515095956.17898-1-zyytlz.wz@163.com/
  https://lore.kernel.org/all/20260505123330.2822833-1-tristmd@gmail.com/
  https://lore.kernel.org/all/20260603171620.2532527-1-jie.wang@intel.com/

A similar use-after-free was reported against 7.0-rc1 in June 2026,
with the free stack in lmLogClose() via jfs_umount(), and syzbot has
an open slab use-after-free write in lmLogSync(); the txEnd() sequence
is unchanged in linux-next 20260727:

  https://lore.kernel.org/all/6a3eedfa.fd822575.2d6b21.e180@mx.google.com/
  https://syzkaller.appspot.com/bug?extid=ea7ed3bb2f444cb4dfeb

CC: Paul Barker <paul@pbarker.dev>
AI-Generated: Uses Claude (claude-opus-5)
Signed-off-by: Junjie Cao <junjie.cao@linux.dev>
---
v4:
- describe the 2026 proposals and reports as similar races rather than
  the same one; drop the kernel-cache configuration paragraph; use the
  review's comment and status wording
- name the open syzbot bug as the lmLogSync write rather than the
  txEnd write

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

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

diff --git a/meta/recipes-kernel/linux/cve-exclusion.inc b/meta/recipes-kernel/linux/cve-exclusion.inc
index 4318fc79..a133bf08 100644
--- a/meta/recipes-kernel/linux/cve-exclusion.inc
+++ b/meta/recipes-kernel/linux/cve-exclusion.inc
@@ -231,3 +231,12 @@ CVE_STATUS[CVE-2022-1247] = "fixed-version: Fixed from version 6.17"
 # https://security-tracker.debian.org/tracker/CVE-2022-4543
 # https://ubuntu.com/security/CVE-2022-4543
 CVE_STATUS[CVE-2022-4543] = "unpatched: No fix has been proposed"
+
+# Triaged August 2026 - Originally proposed fix was withdrawn, similar
+# slab-use-after-free appears to have been re-found by syzkaller in 2026.
+# Unfixed in Debian, "needs evaluation" in Ubuntu.
+# https://lore.kernel.org/lkml/CAJedcCzmx02bfa22QezE8mu-iDsSdSy_oApT2ozCWO8O-8MJEQ@mail.gmail.com/
+# https://syzkaller.appspot.com/bug?extid=ea7ed3bb2f444cb4dfeb
+# 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"
-- 
2.43.0

[OE-core][PATCH v4 7/8] cve-exclusions: set status for CVE-2023-6238

[Junjie Cao]

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

[OE-core][PATCH v4 8/8] cve-exclusions: set status for CVE-2023-6240

[Junjie Cao]

"Marvin" is Hubert Kario's Bleichenbacher-style timing oracle research:

  https://people.redhat.com/~hkario/marvin/

The affected code is the generic software RSA PKCS#1 v1.5 unpadding in
crypto/rsa-pkcs1pad.c. pkcs1pad_decrypt_complete() has three
secret-dependent early exits (leading zero byte, block type, minimum
padding length) and a loop whose trip count depends on the position of
the separator, so the time taken reveals padding validity. There is no
constant-time unpadding or implicit-rejection fallback in the tree.

Red Hat classifies it CWE-203 and has shipped fixes only in RHEL errata
(RHSA-2024:2758, RHSA-2024:3618 and others); the bugzilla is still NEW.
Ubuntu records "appears unfixed in upstream as of 2024.08.24" and
Debian lists src:linux vulnerable in all suites:

  https://access.redhat.com/security/cve/CVE-2023-6240
  https://ubuntu.com/security/CVE-2023-6240
  https://security-tracker.debian.org/tracker/CVE-2023-6240

CC: Paul Barker <paul@pbarker.dev>
AI-Generated: Uses Claude (claude-opus-5)
Signed-off-by: Junjie Cao <junjie.cao@linux.dev>
---
v4:
- drop the practical-exposure paragraph; use the review's comment and
  status wording
- quote Ubuntu's note verbatim

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 4729191a..8714173c 100644
--- a/meta/recipes-kernel/linux/cve-exclusion.inc
+++ b/meta/recipes-kernel/linux/cve-exclusion.inc
@@ -250,3 +250,13 @@ CVE_STATUS[CVE-2023-3397] = "unpatched: Proposed fix was withdrawn"
 # 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"
+
+# Triaged August 2026 - "Marvin" attack, Red Hat reports this fixed but the
+# exact patch is unidentified (see RHSA-2024:2758, RHSA-2024:3618 & others).
+# Unfixed in Debian, "Needs evaluation" in Ubuntu.
+# https://people.redhat.com/~hkario/marvin/
+# https://access.redhat.com/security/cve/cve-2023-6240
+# https://security-tracker.debian.org/tracker/CVE-2023-6240
+# https://ubuntu.com/security/CVE-2023-6240
+CVE_STATUS[CVE-2023-6240] = "unpatched: Fixed in RHEL but patch not identified \
+publicly"
-- 
2.43.0

Re: [OE-core][PATCH v4 0/8] cve-exclusions: triage eight kernel CVEs lacking upstream fix data

[Paul Barker]

On Sun, 2026-08-23 at 23:21 -0500, Junjie Cao wrote:
> This is v4 of the kernel CVE triage from Paul Barker's "linux-yocto
> CVEs in need of triage" request, reworked according to his review of
> v3 [1].
> 
> Changes since v3:
> 
> - Seven entries adopt the comment and CVE_STATUS wordings suggested in
>   [1], including triage dates and distribution tracker links in the
>   .inc comments; the CVE-2022-1247 entry was approved as-is and is
>   unchanged. Commit message detail flagged as unnecessary or
>   time-consuming to validate is dropped. One deviation: the
>   CVE-2023-6238 status reads "Proposed fix was not merged" rather than
>   "withdrawn" - the fix was backed out by the nvme maintainer, not
>   withdrawn by its author - matching the comment above the entry.
> 
> - CVE-2022-0400 stays out of this series as agreed. Red Hat PSIRT has
>   since answered the request for details (ticket PSIRTSUPT-22046) and
>   named the affected code; it is the issue fixed in v6.13 that
>   upstream tracks as CVE-2024-49568, with the details recorded on the
>   public bug [2]. A separate patch records the fixed-version status.
> 
> Summary of the eight verdicts:
> 
>   fixed-version   CVE-2022-1247   6.17, rose_neigh refcount conversion
>   unpatched       CVE-2019-14899  weak host model, no upstream fix
>                   CVE-2021-3714   inherent to KSM deduplication
>                   CVE-2021-3864   proposed fixes not merged
>                   CVE-2022-4543   EntryBleed, no fix proposed
>                   CVE-2023-3397   JFS UAF, proposed fix withdrawn
>                   CVE-2023-6238   NVMe passthrough, fix not merged
>                   CVE-2023-6240   Marvin oracle, fixed only in RHEL
> 
> AI assistance is disclosed with the AI-Generated trailer on each patch.
> 
> Once these are settled I can prepare the wrynose and scarthgap
> backports.
> 
> [1] https://lore.kernel.org/openembedded-core/7b18fd3a5e6b660b9c605671da2b188b5abbf4ba.camel@pbarker.dev/
> [2] https://bugzilla.redhat.com/show_bug.cgi?id=2044575
> 
> v3: https://lore.kernel.org/openembedded-core/20260812072842.1176341-1-junjie.cao@linux.dev/
> v2: https://lore.kernel.org/openembedded-core/20260803084827.1348810-1-junjie.cao@linux.dev/
> 
> Junjie Cao (8):
>   cve-exclusions: set status for CVE-2019-14899
>   cve-exclusions: set status for CVE-2021-3714
>   cve-exclusions: set status for CVE-2021-3864
>   cve-exclusions: set status for CVE-2022-1247
>   cve-exclusions: set status for CVE-2022-4543
>   cve-exclusions: set status for CVE-2023-3397
>   cve-exclusions: set status for CVE-2023-6238
>   cve-exclusions: set status for CVE-2023-6240

These all look good to me now, thanks for working through them!

Best regards,

-- 
Paul Barker