@@ -239,3 +239,8 @@ considered a defence against local attackers"
# https://lore.kernel.org/all/20230515095956.17898-1-zyytlz.wz@163.com/
CVE_STATUS[CVE-2023-3397] = "unpatched: no upstream fix, the only proposed \
patch was withdrawn by its author and the affected fs/jfs code is unchanged"
+
+# Fix https://git.kernel.org/linus/eecd203ada43a4693ce6fdd3a58ae10c7819252c
+# The CVE names usb_giveback_urb(), which does not exist; the reporter's PoC
+# and Ubuntu's break-fix data both point at drivers/media/rc/imon.c.
+CVE_STATUS[CVE-2023-4010] = "fixed-version: Fixed from version 6.18"
The CVE text attributes a system lockup to usb_giveback_urb() in the USB HCD framework. That function does not exist in the kernel; the closest name is usb_giveback_urb_bh(). Ubuntu's security team noted the same discrepancy when triaging the issue. The reporter's proof of concept identifies the actual driver. Its output shows the imon driver repeatedly printing errors and consuming CPU: https://github.com/wanrenmi/a-usb-kernel-bug usb_rx_callback_intf0() and usb_rx_callback_intf1() in drivers/media/rc/imon.c resubmitted the RX URB after logging an error, so a device returning -EPROTO caused an unbounded warning loop. That is fixed by: https://git.kernel.org/linus/eecd203ada43a4693ce6fdd3a58ae10c7819252c ("media: imon: make send_packet() more robust", v6.18) whose commit message describes the same mechanism: "usb_rx_callback_intf0() resubmits urb after printk(), and resubmitted urb causes usb_rx_callback_intf0() to again get -EPROTO error. This results in printk() flooding (RCU stalls)". The fix returns early for those error codes instead of resubmitting. The impact is lower than the CVE suggests. It needs physical access to attach a malicious device, and Ubuntu's triage concluded "There is no system lockup happening", only unthrottled logging: https://ubuntu.com/security/CVE-2023-4010 Ubuntu's tracker data reaches the same conclusion about which driver is at fault: it records "break-fix: 21677cfc562a -" for this CVE, and 21677cfc562a is "V4L/DVB: ir-core: add imon driver", the commit that introduced the driver. Their note explains the choice: "The imon driver has been issuing those warnings since its inception, so using that as the break commit." The tie to the fixing commit is an inference: eecd203ada43 carries no CVE reference or Fixes tag, so no tracker links the two. It rests on the reported function not existing, Ubuntu and the reporter's PoC both pointing at imon, and the mechanism the commit fixes matching the report. 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 | 5 +++++ 1 file changed, 5 insertions(+)