CVE-2026-98766 in Linux
Summary
by MITRE • 10/18/2026
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.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 10/18/2026
The Linux kernel USB gadget subsystem for ASPEED virtual hubs contains a critical use-after-free vulnerability arising from improper lifecycle management of asynchronous work items during device removal. The ast_vhub driver utilizes a wake_work structure to handle remote wakeup events, which are designed to resume suspended downstream ports when triggered by the gadget's wakeup callback. However, the original implementation failed to ensure that this pending work item was properly cancelled before the underlying hardware resources and data structures were deallocated. Specifically, during the device removal process handled by ast_vhub_remove(), the driver did not cancel any queued wake_work items. This oversight creates a race condition where a work item scheduled prior to or during the teardown phase can execute after the devm framework has already freed the vhub structure and its associated ports. When this delayed execution occurs, the kernel attempts to access memory that is no longer valid, leading to a use-after-free condition that can result in system instability, crashes, or potentially exploitable code execution scenarios depending on the state of the freed memory.
The complexity of fixing this vulnerability lies in the asynchronous nature of USB wakeup requests and the lack of locking mechanisms within certain API calls. Simply cancelling the work item is insufficient because usb_gadget_wakeup() does not take a lock to protect its operations. Consequently, an unbind path that clears internal state without holding appropriate synchronization primitives allows a remote-wakeup request originating from another CPU core to re-arm the wake_work after the cancel operation has completed but before the vhub structure is fully freed. This race window permits the work item to be scheduled again on stale memory references. To resolve this, the fix introduces a registration flag check within ast_vhub_udc_wakeup(). The function ast_vhub_del_dev() already clears the d->registered flag under the protection of vhub->lock prior to unregistering the gadget. By refusing wakeup requests once d->registered is cleared, and ensuring that the check for this flag along with the subsequent schedule_work call are atomic relative to the unbind process, the driver effectively prevents new work items from being queued after removal has begun.
The mitigation strategy also addresses edge cases in error handling during device initialization. The fix moves the INIT_WORK() macro invocation to the very beginning of ast_vhub_probe(). This change is necessary because probe failure paths often invoke ast_vhub_remove() for cleanup purposes. Without this adjustment, a failed probe could lead to an attempt to cancel a work item that was never initialized, potentially causing undefined behavior or additional crashes. The corrected logic ensures that any wakeup request arriving after the registration flag has been cleared returns immediately without arming the work queue, while requests that passed the check before the flag was cleared are safely drained by the subsequent call to cancel_work_sync() within the deletion loop. This approach guarantees that no pending operations remain active once the driver's resources are being released, thereby eliminating the race condition entirely.
From a vulnerability classification perspective, this issue aligns with CWE-416, Use After Free, as it involves accessing memory after it has been freed due to improper synchronization and lifecycle management. In terms of attack vectors, this could be leveraged in scenarios where an attacker can trigger USB gadget removal while simultaneously inducing remote wakeup events, potentially leading to denial of service or privilege escalation if the kernel heap state is manipulated favorably. The vulnerability was identified using a static analysis tool, highlighting the importance of automated code inspection for detecting race conditions and resource management errors that are difficult to reproduce through manual testing alone.
To mitigate this risk in environments running affected Linux kernels, it is imperative to apply the latest available security patches provided by your distribution vendor or upstream kernel maintainers. System administrators should monitor for updates related to the USB gadget subsystem and ASPEED hardware support modules. For developers integrating similar asynchronous work patterns into out-of-tree drivers, strict adherence to synchronization primitives such as mutexes or spinlocks when modifying shared state flags is essential. Ensuring that cleanup routines explicitly cancel all pending deferred work before freeing associated data structures remains a fundamental best practice for preventing use-after-free vulnerabilities in kernel space code.