Strix
73.1K

CVE-2026-98766

UnknownEPSS 0.17%

Last modified

CVE-2026-98766 is a vulnerability of currently unknown severity. 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. EPSS estimates a 0.17% chance of exploitation in the next 30 days.

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.

Metrics

EPSS Probability
0.17%

6.0th percentile

Probability of exploitation in the next 30 days. Learn more

Affected Software

Source: CNA advisory (CVE.org). NVD analysis pending.

VendorProductVersions
LinuxLinux>= 7ecca2a4080cb6b1fa174adc588fce9e9014c43c, < 89b3fef8809ec1a9acf5f753eb89b9508d7e4466; >= 7ecca2a4080cb6b1fa174adc588fce9e9014c43c, < 3aed0c86afa7877d08722233a8b15e8c1ff8bcb8; >= 7ecca2a4080cb6b1fa174adc588fce9e9014c43c, < 552f580a18787cfbd83d28d7d76d584c29f2c4c2; >= 7ecca2a4080cb6b1fa174adc588fce9e9014c43c, < 0d39ac4f65f9357469518c70e42940e0d8b0e497; >= 7ecca2a4080cb6b1fa174adc588fce9e9014c43c, < f343bfa3fc9f6255602d66f4a7dbe7ddef13ba41; >= 7ecca2a4080cb6b1fa174adc588fce9e9014c43c, < 474e9e1852fb5ba0bfb26f123dd0cb361d0f4f4d; >= 7ecca2a4080cb6b1fa174adc588fce9e9014c43c, < c81504dfd2d93e345c98e7a012c2f2e74ce5b6a1; >= 7ecca2a4080cb6b1fa174adc588fce9e9014c43c, < 20388c8d1d74c203fec8194c45cd31afdfab934e
LinuxLinux4.18

References

Timeline

Published
Last Modified
Status
Received

Frequently Asked Questions

What is CVE-2026-98766?
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.
How severe is CVE-2026-98766?
Severity scoring for CVE-2026-98766 is pending analysis. The EPSS model estimates a 0.17% probability of exploitation in the next 30 days.
How do I fix CVE-2026-98766?
Check the vendor references and advisories linked above for patched versions and mitigation guidance. You can also run a Strix scan to test if your systems are affected.

How Strix Helps

Related CVEs from 2026

View all 2026CVEs →

Are you affected by CVE-2026-98766?

Run a free Strix scan to check your systems for this vulnerability.

Scan your code now

Source: NVD / NIST