CVE-2026-89738: usb: gadget: at91_udc: drain polled-VBUS timer/work before udc is freed
In the Linux kernel, the following vulnerability has been resolved:
usb: gadget: at91udc: drain polled-VBUS timer/work before udc is freed
In polled-VBUS mode (board.vbuspin && board.vbuspolled), probe arms a self-restarting cycle: at91vbustimer() schedules vbustimerwork, and at91vbustimerwork() calls at91vbusupdate() and re-arms the timer via modtimer(). Both recover the same udc through containerof and dereference it on every iteration.
Neither teardown path cancels this cycle. udc is devm-allocated, so it is freed after at91udcremove() returns, and is likewise freed when probe fails and devres runs. A timer callback or work item that is pending or running at either point dereferences the freed udc.
Add at91udcshutdownvbustimer() and call it from at91udcremove() and from the usbaddgadgetudc() failure path in probe; the remaining probe error paths fail before the timer is armed. timershutdownsync() waits for a running callback and clears timer->function, which makes the work handler's modtimer() a permanent no-op; cancelworksync() then drains any pending or running work whose re-arm attempt now does nothing. The timer must be shut down first, since cancelling the work alone would let the timer re-queue it. The guard mirrors probe: in IRQ mode the timer and workstruct are never initialized.
This does not require a fault; a normal driver unbind can interleave with an already queued work item.
This issue was found by an in-house static analysis tool.
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Compensating control
Drain/cancel the polled-VBUS timer/work before freeing the devm-allocated at91 UDC (ensure the teardown path shuts down the self-restarting vbus_timer cycle so no running/pending callback dereferences a freed udc).
Event History
Frequently Asked Questions
Which systems are exposed to this use-after-free condition?
Systems using the Linux at91_udc USB gadget driver in polled-VBUS mode are exposed. The affected mode is enabled when both board.vbus_pin and board.vbus_polled are configured.
When can the issue be triggered?
The stale timer callback or work item can dereference freed driver state during device removal or when probe fails after the polled-VBUS timer cycle has been armed. The timer and work item continuously re-arm each other unless teardown drains them.
Is the default or every at91_udc configuration affected?
No. The described condition is specific to polled-VBUS mode; probe error paths that fail before the timer is armed are not affected.
What mitigation is available if the fix cannot be deployed immediately?
Avoid enabling polled-VBUS mode for the at91_udc driver, meaning do not use the configuration where both board.vbus_pin and board.vbus_polled are set.