CVE-2026-74677
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
__r
CSIRTS triage
- What
- Use-after-free in ipheth USB driver's carrier_work function triggered during device disconnect.
- Who is affected
- Systems using Apple iPhone USB Ethernet driver (ipheth) that disconnect devices during active use.
- Urgency
- Medium severity (CVSS 4.2) with no current exploitation; requires specific USB device interaction.
- Action
- Apply Linux kernel patch to properly cancel carrier_work before device disconnect in ipheth driver.
AI-assisted analysis generated from the source advisory — verify against the original.
⚡ Watch CVE-2026-74677
Get an email if CVE-2026-74677 is added to CISA KEV, gains public exploit code, or a new advisory cites it — max one per day, one-click unsubscribe.
Exploitation outlook
- Low exploitation risk0.17% 30-day exploitation probability — currently an unlikely target, but scores change as exploit code circulates. Riskier than 6% of all EPSS-scored CVEs.
Advisory coverage (2)
- unknownCVE-2026-74677: In the Linux kernel, the following vulnerability has been resolved: net: usb: ipheth: fix carr…nvd · 2026-08-22
- mediumCVE-2026-74677: net: usb: ipheth: fix carrier_work UAF on disconnectmsrc · 2026-08-11
External references
Embed the live status
— this badge updates automatically when the KEV or exploit status changes. How to embed it →
[](https://www.csirts.com/cve/CVE-2026-74677)