mbox series

[v2,00/10] cve-exclusion: triage ten kernel CVEs lacking upstream fix data

Message ID 20260803084827.1348810-1-junjie.cao@linux.dev
Headers show
Series cve-exclusion: triage ten kernel CVEs lacking upstream fix data | expand

Message

Junjie Cao Aug. 3, 2026, 8:48 a.m. UTC
This is v2 of the triage of the CVEs from Paul Barker's "linux-yocto CVEs
in need of triage" request [1], reworked according to his review [2]:
one patch per CVE, primary sources cited in every commit message, and
the three CVEs which have no upstream fix recorded as "unpatched" rather
than left out.

CVE-2023-3640 is not included; Adhitya is handling that one.

Summary of the ten verdicts:

  fixed-version     CVE-2022-1247   v6.17, rose_neigh refcount conversion
                    CVE-2023-4010   v6.18, imon URB resubmit loop
  disputed          CVE-2022-0400   never substantiated, closed by three vendors
  upstream-wontfix  CVE-2019-14899  weak host model, config-only mitigation
                    CVE-2021-3714   inherent to KSM deduplication
                    CVE-2021-3864   two fix attempts, neither merged
                    CVE-2022-4543   KASLR not a boundary against local attackers
  unpatched         CVE-2023-3397   JFS txEnd UAF, proposed fix withdrawn
                    CVE-2023-6238   NVMe fix applied then reverted
                    CVE-2023-6240   RSA timing oracle, fixed only in RHEL

Every commit referenced above was verified to exist and to be contained in
the stated release using git tag --contains against mainline history at
linux-next 20260727.

Two points for reviewer attention:

- CVE-2023-4010 (patch 8) is the one identification that rests on
  inference rather than an authoritative statement: the fixing commit
  carries no CVE reference. The reasoning is spelled out in the commit
  message; "disputed" would also be defensible and I am happy to respin
  that patch if preferred.

- CVE-2022-1247 (patch 5) is fixed in v6.17, but no distribution tracker
  has connected the fix to the CVE yet. If the conclusion looks right it
  would be worth reporting back to Ubuntu, Debian and Red Hat.

The AI-Generated trailer on each patch covers source research and the
drafting of the commit messages. Every commit hash, release attribution
and quotation was verified against mainline git history and the cited
sources before submission, and I take responsibility for the
conclusions.

Once these are settled I am happy to prepare the wrynose and scarthgap
backports.

[1]: https://lore.kernel.org/all/4ac849a706feb16688020d5bcc3e74aececd63cf.camel@pbarker.dev/
[2]: https://lore.kernel.org/openembedded-core/95aae562c0b8862ac687a63e8003143044519d6e.camel@pbarker.dev/

changes in v2:
- split out of the single combined patch, one CVE per patch as requested
- added primary source links (disclosures, distribution trackers, mailing
  list threads, upstream commits) to every commit message
- added the three CVEs with no upstream fix as "unpatched" entries instead
  of leaving them undocumented
- disclosed AI assistance per the contributor guide

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

Junjie Cao (10):
  cve-exclusion: set status for CVE-2019-14899
  cve-exclusion: set status for CVE-2021-3714
  cve-exclusion: set status for CVE-2021-3864
  cve-exclusion: set status for CVE-2022-0400
  cve-exclusion: set status for CVE-2022-1247
  cve-exclusion: set status for CVE-2022-4543
  cve-exclusion: set status for CVE-2023-3397
  cve-exclusion: set status for CVE-2023-4010
  cve-exclusion: set status for CVE-2023-6238
  cve-exclusion: set status for CVE-2023-6240

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