CVE-2026-74677net: usb: ipheth: fix carrier_work UAF on disconnect
- —Not scoredno CVSS score yet
- 0.17%Exploitation in 30 daysEPSS · top 94% of all CVEs
- NoKnown exploitednot in CISA's KEV catalog
- NonePublic exploitsnone known yet
Description
In the Linux kernel, the following vulnerability has been resolved: net: usb: ipheth: fix carrier_work UAF on disconnect ipheth_sndbulk_callback() re-arms the carrier-check work on any non-zero URB status: else schedule_delayed_work(&dev->carrier_work, 0); Nothing ties that to the interface being up, so the work can be armed again after ipheth_close() has already drained it, and stay armed until the netdev whose private area embeds it is freed. On unplug with a TX URB in flight, ipheth_disconnect() drains the work through unregister_netdev() -> ipheth_close() -> cancel_delayed_work_sync() and only then calls ipheth_kill_urbs(). usb_kill_urb() completes the in-flight TX URB with -ENOENT, so ipheth_sndbulk_callback() runs after the drain and re-arms carrier_work. The same completion also re-arms the work if the interface is only brought down while a TX URB is in flight, and ipheth_carrier_check_work() then keeps re-queueing itself once a second. unregister_netdev() does not call ipheth_close() for an already-down interface, so nothing drains it on the later unplug either. In both cases free_netdev() frees the netdev while carrier_work is still pending, and ipheth_carrier_check_work() dereferences freed memory. Tie the work to the interface state instead of chasing the completion: disable it in ipheth_close() and enable it in ipheth_open(), so a schedule_delayed_work() from the URB completion is a no-op whenever the interface is not up. disable_delayed_work_sync() also waits for a running instance, so it fully replaces the cancel_delayed_work_sync() it takes the place of. The work starts out disabled in ipheth_probe() so the enable/disable counts balance from the first open. Reproduced under KASAN on linux-next (next-20260731) with dummy_hcd and raw-gadget standing in for the device, driving the second path above (the interface is already down, so unregister_netdev() does not call ipheth_close()): 15 of 15 unpatched boots report a slab-use-after-free in __run_timers(), freed by ipheth_disconnect() and re-armed from ipheth_sndbulk_callback() via queue_delayed_work_on(). The same trigger on a kernel differing only by this patch reports 0 of 15, and the carrier check still functions across open/close cycles. The reproducer needs an attached USB device that stops draining bulk OUT, plus a link down and unplug, driven as root. It is not a privilege boundary crossing and no exploit primitive was developed. Found by 0sec (https://0sec.ai).
Timeline
ID reserved
By Linux
- 7 days later
· 7 days later
Published
Changes after publication (a new score, a public exploit, EPSS crossing 1, 10 or 50 %, leaving KEV) are kept since November 2026; earlier ones are not known.
Scores
No CVSS score yet: neither the CNA, CISA nor NVD has scored this CVE. NVD status: Received.
- EPSS (exploitation in 30 days)
- 0.17% · top 94% of all CVEs (15 Nov 2026)
The list uses the assigner's score when there is one, then CISA's, then NVD's: Not scored.
Affected products
- affected bb1b40c7cb863f0800a6410c7dcb86cf3f28d3b1 – < d07133fe1befae9a1e4c4c5e46ef0b73d2992020
- affected bb1b40c7cb863f0800a6410c7dcb86cf3f28d3b1 – < 2c7496124e94c7f9c3daa5c5b1fb563ca9d62c45
- affected bb1b40c7cb863f0800a6410c7dcb86cf3f28d3b1 – < 48303f3ae0fa6e102f3fc7dbf1688cc179131962
- affected bb1b40c7cb863f0800a6410c7dcb86cf3f28d3b1 – < fde39b8a521780391fb4e5bda2c0aa4928947f12
- affected 4f2df9fd07698bece3321fbf9e4b6dbcb9babccc
- affected ea7d6be58c2e6c1f426b48994bb22b2393c90963
- affected f5bca75dc46701f4c0d1dcbaae401233ae7ff06b
- affected 4.4.180 – < 4.5
- affected 4.9.173 – < 4.10
- affected 4.14.116 – < 4.15
- affected 4.15
- unaffected < 4.15
- unaffected 6.12.104 – ≤ 6.12.*
- unaffected 6.18.45 – ≤ 6.18.*
- unaffected 7.1.9 – ≤ 7.1.*
- unaffected 7.2 – ≤ *
References
References4
- https://git.kernel.org/stable/c/d07133fe1befae9a1e4c4c5e46ef0b73d2992020 (opens in a new tab)
- https://git.kernel.org/stable/c/2c7496124e94c7f9c3daa5c5b1fb563ca9d62c45 (opens in a new tab)
- https://git.kernel.org/stable/c/48303f3ae0fa6e102f3fc7dbf1688cc179131962 (opens in a new tab)
- https://git.kernel.org/stable/c/fde39b8a521780391fb4e5bda2c0aa4928947f12 (opens in a new tab)
Sources
The same CVE in the primary databases and aggregators, to check against.
- CVE.org record (opens in a new tab)
- CVE List JSON (GitHub) (opens in a new tab)
- NVD (opens in a new tab)
- FIRST EPSS (opens in a new tab)
- EUVD EUVD-2026-64364 (opens in a new tab)
- OSV.dev (opens in a new tab)
- GitHub Advisories (opens in a new tab)
- CIRCL Vulnerability-Lookup (opens in a new tab)
Badge for a README or a ticket
[](https://cveledger.app/cve/CVE-2026-74677)Record last updated .