@@ -219,3 +219,9 @@ several attempts, exploitation requires a relative kernel.core_pattern"
# https://bugzilla.redhat.com/show_bug.cgi?id=2044575
CVE_STATUS[CVE-2022-0400] = "disputed: the reported net/smc out-of-bounds read \
was never substantiated and was closed as not-a-bug by Red Hat, SUSE and Debian"
+
+# Fix https://git.kernel.org/linus/d860d1faa6b2ce3becfdb8b0c2b048ad31800061
+# Fix https://git.kernel.org/linus/da9c9c877597170b929a6121a68dcd3dd9a80f45
+# Also in 6.1.150, 6.6.104, 6.12.y and 6.16.5 via the 2025-09-02 stable round.
+# The rose/hamradio subsystem was removed entirely in v7.1 (dd8d4bc28ad7).
+CVE_STATUS[CVE-2022-1247] = "fixed-version: Fixed from version 6.17"
The CVE describes a race between rose_connect() and the code that frees a rose_neigh once its count and use fields reach zero. Takamitsu Iwai's August 2025 series converts that field to a proper reference count and removes the unlocked increment in rose_connect() which is exactly the operation the CVE describes: 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 first commit message states the premise of the CVE almost verbatim: "The 'use' field in struct rose_neigh is used as a reference counter but lacks atomicity. This can lead to race conditions where a rose_neigh structure is freed while still being referenced by other code paths", and its diff deletes the "rose->neighbour->use++;" statement from rose_connect(). The second merges the separate count and use counters, which is the other half of the condition described by the CVE, and closes a syzbot-reported slab-use-after-free. Both are in v6.17 and were backported to 6.1.y, 6.6.y, 6.12.y and 6.16.y in the 2025-09-02 stable round. Kernels from v7.1 onwards are unaffected by construction, since the AX.25 and hamradio subsystems were removed: https://git.kernel.org/linus/dd8d4bc28ad7252610d8e79c1313a2d1e3499a51 The commits predate the association of this CVE with any fix, so no tracker links them yet - Ubuntu, Debian and Red Hat all still show the CVE as open. The identification above is based on the commit contents matching the CVE description; the two 2022 rose patches from Duoming Zhou that Ubuntu's tracker references fix different rose bugs and are not the fix for this issue. CC: Paul Barker <paul@pbarker.dev> AI-Generated: Uses Claude (claude-opus-5) Signed-off-by: Junjie Cao <junjie.cao@linux.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/ meta/recipes-kernel/linux/cve-exclusion.inc | 6 ++++++ 1 file changed, 6 insertions(+)