On Wed, 2026-08-12 at 02:28 -0500, Junjie Cao wrote: > This is v3 of the kernel CVE triage from Paul Barker's "linux-yocto CVEs > in need of triage" request, reworked according to his review of v2 [1]. > > Main changes since v2: > > - Dropped the CVE-2023-4010 (imon) patch. The identification rested on > inferring the reporter's intent from a screenshot, which the review > rejected. The CVE record names a function that does not exist in the > kernel (usb_giveback_urb()); I have reported that defect to the > assigning CNA and left the CVE untriaged here. > > - Moved the four entries that used "upstream-wontfix" (CVE-2019-14899, > CVE-2021-3714, CVE-2021-3864, CVE-2022-4543) to "unpatched". None has > an upstream kernel-community wontfix statement; the WONTFIX and > deferred positions are distribution ones. "unpatched" keeps them > visible in reports. > > - CVE-2022-1247 now leads with the v7.1 removal of net/rose and keeps > the v6.17 refcount commits, which are what cover the 6.18 kernel on > master. Upstream has since assigned those two commits CVE-2025-39826 > and CVE-2025-39827, so the identification no longer rests on reading > the diff alone. > > - CVE-2023-3397: corrected the claim that only one fix was proposed and > withdrawn; further fixes were posted in 2026 but none is merged, and > syzbot still reproduces the txEnd()/lmLogClose() unmount race. > > - CVE-2023-6240: dropped the Marvell/s390 aside and an unrelated commit > reference flagged in review. > > CVE-2022-0400 and CVE-2023-6238 are unchanged since v2. > > AI assistance is disclosed with the AI-Generated trailer on each patch. > > Summary of the nine verdicts: > > fixed-version CVE-2022-1247 6.17, rose_neigh refcount conversion > disputed CVE-2022-0400 never substantiated, closed by three vendors > unpatched CVE-2019-14899 weak host model, config-only mitigation > CVE-2021-3714 inherent to KSM deduplication > CVE-2021-3864 two mitigation attempts, neither merged > CVE-2022-4543 KASLR not a boundary against local attackers > CVE-2023-3397 JFS txEnd UAF, no fix merged > CVE-2023-6238 NVMe fix applied then reverted > CVE-2023-6240 RSA timing oracle, fixed only in RHEL > > Once these are settled I can prepare the wrynose and scarthgap backports.
Hi, I have spent some time validating the status of all the issues and I think we're nearly there. I've suggested changes to the commit messages, comments and CVE_STATUS wordings, with those addressed I think 8/9 of these will be ready to merge. CVE-2022-0400 still bothers me. There was clearly something reported, there's a non-public Red Hat bugzilla entry referenced by Debian [1]. It looks like it was closed by Red Hat, SUSE and Debian as they don't build the affected code, not because it was an invalid report. We should ask Red Hat to release more details. [1]: https://bugzilla.redhat.com/show_bug.cgi?id=2040604 Best regards, -- Paul Barker
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#243540): https://lists.openembedded.org/g/openembedded-core/message/243540 Mute This Topic: https://lists.openembedded.org/mt/120714046/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
