AZL-97161

In the Linux kernel, the following vulnerability has been resolved:

net: usb: ipheth: fix carrier_work UAF on disconnect

iphethsndbulkcallback() 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, iphethdisconnect() drains the work through unregisternetdev() -> iphethclose() -> canceldelayedworksync() and only then calls iphethkillurbs(). usbkillurb() completes the in-flight TX URB with -ENOENT, so iphethsndbulkcallback() 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 iphethcarriercheckwork() then keeps re-queueing itself once a second. unregisternetdev() does not call ipheth_close() for an already-down interface, so nothing drains it on the later unplug either.

In both cases freenetdev() frees the netdev while carrierwork is still pending, and iphethcarriercheck_work() dereferences freed memory.

Tie the work to the interface state instead of chasing the completion: disable it in iphethclose() and enable it in iphethopen(), so a scheduledelayedwork() from the URB completion is a no-op whenever the interface is not up. disabledelayedworksync() also waits for a running instance, so it fully replaces the canceldelayedworksync() 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 dummyhcd and raw-gadget standing in for the device, driving the second path above (the interface is already down, so unregisternetdev() does not call ipheth_close()): 15 of 15 unpatched boots report a slab-use-after-free in _runtimers(), freed by iphethdisconnect() and re-armed from iphethsndbulkcallback() via queuedelayedworkon(). 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).