CVE-2026-98766: Linux kernel · usb: gadget: aspeed-vhub: cancel wake work on device removal
Affects Linux kernelSource CVE Database V5
Not known to be exploited · fixed in f343bfa3fc9f6255602d66f4a7dbe7ddef13ba41 : update Linux kernel when convenient.
Data as of 26 Oct 2026, 14:18 UTC
Rated by Threat Radar · CVSS not yet scored by NVD
- EPSS
- 0.1% chance of exploitation in 30 days – higher than 5% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
- Patch
- Available – fixed in f343bfa3fc9f6255602d66f4a7dbe7ddef13ba41, c81504dfd2d93e345c98e7a012c2f2e74ce5b6a1, 20388c8d1d74c203fec8194c45cd31afdfab934e +2
Exploitation evidence
Disclosed: evidence found.
CVE published 18 Oct 2026
Detectable: no evidence on record.
No public nuclei template indexed
Weaponised: no evidence on record.
No public exploit code indexed in Metasploit or Exploit-DB
Exploited in the wildExploited: no evidence on record.
Not in CISA KEV and no source reports exploitation
Observed by OffSeq MirageSeen by Mirage: no evidence on record.
No attack traffic recorded by OffSeq Mirage sensors
A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 26 Oct 2026.
What to do
Upgrade to a fixed release listed under Affected software.
Affected software
| Product | Affected | Fixed in |
|---|---|---|
| LinuxLinux | Affected
| Fixed in
|
| LinuxLinux | Affected
| Fixed in
|
| LinuxLinux | Affected
| Fixed in
|
| LinuxLinux | Affected
| Fixed in
|
| LinuxLinux | Affected
| Fixed in
|
| LinuxLinux | Affected
| Fixed in– |
Description
In the Linux kernel, the following vulnerability has been resolved: usb: gadget: aspeed-vhub: cancel wake work on device removal wake_work is armed from the gadget .wakeup callback to resume suspended downstream ports, and it is never cancelled in ast_vhub_remove(), 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: usb_gadget_wakeup() takes no lock and the unbind path never clears wakeup_en, so a remote-wakeup request in flight on another CPU can re-arm the work after the cancel and before vhub is freed. ast_vhub_del_dev() already clears d->registered under vhub->lock before unregistering the gadget. Refuse the wakeup in ast_vhub_udc_wakeup() once d->registered is clear: the check and the schedule_work() are then atomic against the unbind, so a wakeup that passed before the flag was cleared is drained by the cancel_work_sync() after the del_dev loop, and one that arrives later returns without arming. Also move INIT_WORK() to the top of ast_vhub_probe(), since the probe error path reuses ast_vhub_remove() and would otherwise cancel a never-initialized work item. This issue was found by an in-house static analysis tool.
References
- git.kernel.org/stable/c/0d39ac4f65f9357469518c70e42940e0d8b0e497 (opens in a new tab)
- git.kernel.org/stable/c/f343bfa3fc9f6255602d66f4a7dbe7ddef13ba41 (opens in a new tab)
- git.kernel.org/stable/c/474e9e1852fb5ba0bfb26f123dd0cb361d0f4f4d (opens in a new tab)
- git.kernel.org/stable/c/c81504dfd2d93e345c98e7a012c2f2e74ce5b6a1 (opens in a new tab)
- git.kernel.org/stable/c/20388c8d1d74c203fec8194c45cd31afdfab934e (opens in a new tab)