Cloudanix VulnDB

CVE-2026-98766

None

CVSS

—

EPSS

0.2%

Published

Oct 18, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A bug in Linux USB handling for certain hardware controllers can let a carefully timed device unplug crash the whole system or open the door to deeper attacks.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
Moderate
Impact
Privilege Gain
Component
OS kernel
Class
Use After Free
Remediation
Patch
Effort
Medium
Patch risk
Low

What it actually does

A use-after-free occurs in the Linux kernel ASPEED vhub USB gadget driver when a scheduled wake_work item executes after devm-managed vhub and port structures are freed during ast_vhub_remove, because the work is never cancelled and a concurrent usb_gadget_wakeup can re-arm it after cancel but before free due to missing registered flag checks.

Why it matters to the business

Embedded systems, BMCs, or servers relying on the ASPEED virtual USB hub driver face kernel instability, crashes, or potential code execution, increasing downtime and patching urgency on affected hardware even with low exploit maturity.

How an attack unfolds

An attacker triggers concurrent gadget wakeup and device removal paths; a wakeup request races past the cancel, re-arms the work after the registered flag is cleared but before structures are freed, and the dangling work item then dereferences freed memory.

How to fix it

Apply the upstream fix that moves INIT_WORK to probe start, cancels wake_work in ast_vhub_remove, clears wakeup_en under lock, and refuses wakeup once d->registered is cleared; rebuild and deploy the patched kernel on all systems using the aspeed-vhub driver.

How to confirm the fix worked

Confirm the fix commit is present in the running kernel source, verify that ast_vhub_remove calls cancel_work_sync on wake_work, and test probe/remove cycles under concurrent wakeup load to ensure no post-free work execution.

Typical attack path

  1. Obtain sufficient privileges to interact with USB gadget interfaces
  2. Trigger usb_gadget_wakeup while ast_vhub_remove is executing
  3. Exploit the window between cancel_work_sync and structure free to execute the work item
  4. Achieve use-after-free dereference for crash or further exploitation

How to detect it

Inspect kernel logs and dmesg for oops/panic traces referencing aspeed-vhub, wake_work, or use-after-free in usb/gadget; correlate USB gadget bind/unbind events with subsequent crashes; review audit logs for unusual gadget wakeup activity on multi-CPU systems.

What your security team should do

  • Prioritize kernel updates on all hosts exposing the aspeed-vhub driver within the next maintenance window
  • Enable kernel hardening features such as KASAN and hardened usercopy to detect UAF attempts
  • Restrict unprivileged access to USB gadget sysfs and character devices where feasible
  • Monitor vendor kernel advisories for backported fixes in LTS branches

The record

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.

Affected packages

Ecosystem Package Introduced Fixed