CVE-2026-98766: usb: gadget: aspeed-vhub: cancel wake work on device removal
In the Linux kernel, the following vulnerability has been resolved:
usb: gadget: aspeed-vhub: cancel wake work on device removal
wakework is armed from the gadget .wakeup callback to resume suspended downstream ports, and it is never cancelled in astvhubremove(), so a work item queued before or during removal can run after devm has freed vhub and its ports, a use-after-free.
Cancelling the work alone is not sufficient: usbgadgetwakeup() takes no lock and the unbind path never clears wakeupen, so a remote-wakeup request in flight on another CPU can re-arm the work after the cancel and before vhub is freed.
astvhubdeldev() already clears d->registered under vhub->lock before unregistering the gadget. Refuse the wakeup in astvhubudcwakeup() once d->registered is clear: the check and the schedulework() are then atomic against the unbind, so a wakeup that passed before the flag was cleared is drained by the cancelworksync() after the deldev loop, and one that arrives later returns without arming. Also move INITWORK() to the top of astvhubprobe(), since the probe error path reuses astvhubremove() and would otherwise cancel a never-initialized work item.
This issue was found by an in-house static analysis tool.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
debian/linuxto a version that resolves this vulnerability.Fixed in 6.12.113-1 - Upgrade
Upgrade
debian/linuxto a version that resolves this vulnerability.Fixed in 7.2.10-1 - Upgrade
Upgrade
debian/linux-6.12to a version that resolves this vulnerability.Fixed in 6.12.113-1~deb12u1 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 5.10.273 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 5.15.224 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 6.1.191 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 6.6.160 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 6.12.113 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 6.18.56 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 7.2.10 - Upgrade
Upgrade
debian/linuxto a version that resolves this vulnerability.Fixed in 6.12.115-2Fixed in 7.2.12-1Fixed in 7.2.15-1 - Compensating control
In the Aspeed vHub driver, initialize wake_work at the top of ast_vhub_probe(); in ast_vhub_remove(), after the del_dev loop, call cancel_work_sync(); and in ast_vhub_udc_wakeup(), refuse the wakeup once d->registered is clear so the check and schedule_work() are atomic against unbind.
Event History
Frequently Asked Questions
Which systems are exposed to this issue?
Systems using the Linux kernel Aspeed vHub USB gadget driver are exposed. The vulnerable path involves suspended downstream ports and the driver's remote-wakeup handling during device removal.
What timing is required to trigger the use-after-free?
A remote-wakeup request must queue, or race to re-queue, wake_work while the vHub device is being removed. Without the fix, the queued work can run after device-managed memory for the vHub and its ports has been freed.
How does the fix prevent the race?
The fix rejects wakeup requests after the device's registered flag is cleared under the vHub lock, making that check atomic with work scheduling relative to unbind. It then synchronously cancels pending wake work after device removal, draining work that was queued before unbind.
How can I determine whether a system has the remediation?
Check whether the kernel includes one of the referenced stable commits: f343bfa3fc9f6255602d66f4a7dbe7ddef13ba41, 474e9e1852fb5ba0bfb26f123dd0cb361d0f4f4d, or c81504dfd2d93e345c98e7a012c2f2e74ce5b6a1. The data does not provide affected or fixed kernel version numbers.