https://db.gcve.eu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Tue, 03 Nov 2026 19:45:07 +0000 https://db.gcve.eu/vuln/cve-2026-98766 <p><strong>Affected:</strong> Linux</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>usb: gadget: aspeed-vhub: cancel wake work on device removal</p> <p>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.</p> <p>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.</p> <p>ast_vhub_del_dev() already clears d-&gt;registered under vhub-&gt;lock before unregistering the gadget. Refuse the wakeup in ast_vhub_udc_wakeup() once d-&gt;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.</p> <p>This issue was found by an in-house static analysis tool.</p> <p><strong>Affected:</strong> Linux</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>usb: gadget: aspeed-vhub: cancel wake work on device removal</p> <p>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.</p> <p>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.</p> <p>ast_vhub_del_dev() already clears d-&gt;registered under vhub-&gt;lock before unregistering the gadget. Refuse the wakeup in ast_vhub_udc_wakeup() once d-&gt;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.</p> <p>This issue was found by an in-house static analysis tool.</p> https://db.gcve.eu/vuln/cve-2026-98766