CVE-2026-89738
High · 7.8CVSS
7.8
EPSS
0.2%
Published
Sep 11, 2026
CISA due date
—
Cloudanix analysis
A bug in the Linux kernel's USB handling for certain chips can let a logged-in user crash the machine or potentially take full control.
- Exploitation
- Local Privilege
- Attacker needs
- Local User
- Complexity
- Moderate
- Impact
- Full Compromise
- Component
- OS kernel
- Class
- Use After Free
- Remediation
- Upgrade
- Effort
- Medium
- Patch risk
- Low
What it actually does
Use-after-free in the at91_udc USB gadget driver: in polled-VBUS mode the self-restarting vbus_timer_work and at91_vbus_timer callbacks continue to dereference a container_of-derived udc pointer after devm-managed memory has been released during remove or probe failure.
Why it matters to the business
Local attackers can trigger kernel memory corruption on affected Linux systems, resulting in crashes, denial of service, or potential privilege escalation to kernel level on devices using the at91_udc controller.
How an attack unfolds
An attacker with local access causes or waits for at91udc_remove (or a probe error path) to free the udc while a pending timer or work item is still scheduled; the callback then dereferences the already-freed structure, achieving a use-after-free without needing special hardware or network access.
How to fix it
Apply a kernel update containing the at91_udc_shutdown_vbus_timer function that calls timer_shutdown_sync followed by cancel_work_sync from both at91udc_remove and the usb_add_gadget_udc failure path; rebuild and reboot with the patched kernel.
How to confirm the fix worked
Confirm the shutdown helper is present and invoked in the remove and probe-error paths, then exercise repeated bind/unbind cycles while monitoring for use-after-free warnings or crashes in dmesg.
Typical attack path
- Obtain local shell or user context on the target Linux system
- Trigger driver unbind, module removal, or a failing probe sequence for at91_udc
- Allow the still-armed timer/work to execute and dereference the freed udc object
How to detect it
Search kernel logs and crash dumps for at91_udc, vbus_timer_work, or container_of references that coincide with driver unload or probe failure; look for general use-after-free or slab corruption reports involving the udc structure.
What your security team should do
- Prioritize kernel updates on all systems exposing the at91_udc driver
- Restrict local user accounts and module loading where the driver is not required
- Include at91_udc-related oops and slab-use-after-free events in kernel logging and alerting
The record
In the Linux kernel, the following vulnerability has been resolved: usb: gadget: at91_udc: drain polled-VBUS timer/work before udc is freed In polled-VBUS mode (board.vbus_pin && board.vbus_polled), probe arms a self-restarting cycle: at91_vbus_timer() schedules vbus_timer_work, and at91_vbus_timer_work() calls at91_vbus_update() and re-arms the timer via mod_timer(). Both recover the same udc through container_of and dereference it on every iteration. Neither teardown path cancels this cycle. udc is devm-allocated, so it is freed after at91udc_remove() 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 at91_udc_shutdown_vbus_timer() and call it from at91udc_remove() and from the usb_add_gadget_udc() failure path in probe; the remaining probe error paths fail before the timer is armed. timer_shutdown_sync() waits for a running callback and clears timer->function, which makes the work handler's mod_timer() a permanent no-op; cancel_work_sync() 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 work_struct 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.
Affected packages
| Ecosystem | Package | Introduced | Fixed |
|---|