Hi Paul, On Thu, 2026-08-06 at 12:52 +0100, Paul Barker wrote: > We briefly discussed this patch series on the review call today. We're > concerned about taking CVE status changes based on AI-Generated analysis > from a new contributor, when there are multiple ways to interpret the > various discussions online about these issues and it's not immediately > clear what the "right" answer is. So we need to give these patches a > thorough review. As we often point out in the weekly status emails, we > have limited bandwidth to do this sort of in-depth review, so we may not > be able to handle these patches quickly.
Thanks very much for your time and reply - understood, and no urgency from my side. For v3 I'll drop the one inferred verdict and downgrade the four "upstream-wontfix" entries to "unpatched", so what's left should be checkable from the links in each commit message. Happy to go through any of these on a review call if that's easier. > > fixed-version CVE-2022-1247 v6.17, rose_neigh refcount conversion > > rose_connect() is now gone from mainline, so we can easily say this was > fixed with the removal of net/rose. Pointing at an earlier fix requires > more detailed review. I'll lead with the removal in the entry. Since master's linux-yocto is 6.18 and the removal (dd8d4bc28ad7) is v7.1, the entry still needs the v6.17 commits to cover 6.18. The kernel CNA later assigned those two commits CVEs of their own (CVE-2025-39826/39827), which ties them to this rose_neigh race in upstream's records. > > CVE-2023-4010 v6.18, imon URB resubmit loop > > This sounds like we're trying to infer the reporter's intent based on > 'imon' being visible in a screenshot. We shouldn't be making guesses > just because the initial report quality is poor. OK, I'll drop this patch and leave the CVE untriaged. The record names a function that does not exist in the kernel, so I'll raise that with the assigning CNA; if the record gets corrected or disputed the status can follow it. > > upstream-wontfix CVE-2019-14899 weak host model, config-only mitigation > > We shouldn't use upstream-wontfix unless that is an actual upstream > opinion. Ubuntu/RedHat are not upstream for the Linux kernel. Right. None of the four has an upstream wontfix statement, so I'll move CVE-2019-14899, CVE-2021-3714, CVE-2021-3864 and CVE-2022-4543 to "unpatched" and put the distro references in the comments. > > CVE-2021-3864 two fix attempts, neither merged > > As above. Was the fix actually rejected by upstream or did it just go quiet? Went quiet, mostly. Eric Biederman called Waiman Long's patch "not a particularly effective mitigation", Linus suggested a different approach, Willy Tarreau posted WIP patches for it, and that petered out in early 2022 with nothing merged. Wander Lairson Costa's RFC v2 got design feedback and no v3 followed. The "NAKed" in my patch 3 message overstates this - I'll fix that wording in v3. > > unpatched CVE-2023-3397 JFS txEnd UAF, proposed fix withdrawn > > Unclear if there is still a real problem here in mainline. The txEnd() sequence is unchanged in linux-next 20260727, and the use-after-free was reported again this June against 7.0-rc1, with the free stack in lmLogClose() via jfs_umount(), which is the race this CVE describes: https://lore.kernel.org/all/[email protected]/ I'll add the link to the commit message. > > CVE-2023-6240 RSA timing oracle, fixed only in RHEL > > Also probably correct but not completely sure. The commit message has > artifacts of the LLM being confused (Marvell/s390/unrelated commit > reference), those can be dropped. Will drop those. Best regards, Junjie
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#243118): https://lists.openembedded.org/g/openembedded-core/message/243118 Mute This Topic: https://lists.openembedded.org/mt/120574077/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
