CVE-2026-98500 in Linux
Summary
by MITRE • 10/18/2026
In the Linux kernel, the following vulnerability has been resolved:
HID: hid-oxp: use cancel_delayed_work_sync() in remove
oxp_hid_remove() uses cancel_delayed_work() for all three delayed work items. cancel_delayed_work() only dequeues a pending work item without waiting for a currently executing callback to finish. If any of the work callbacks (oxp_rgb_queue_fn, oxp_btn_queue_fn, oxp_mcu_init_fn) is running at the time of removal, the callback continues executing concurrently with hid_hw_close() and hid_hw_stop(), accessing the HID device after it has been closed and stopped.
Use cancel_delayed_work_sync() instead to ensure that any in-progress work callback completes before device teardown proceeds.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/18/2026
The vulnerability identified within the Linux kernel's Human Interface Device subsystem, specifically affecting the oxp_hid driver, stems from a race condition during device removal operations. The core issue lies in the improper synchronization mechanism used when tearing down the hardware interface. When the system initiates the removal process for an OXPOSIS HID device, the driver invokes the oxp_hid_remove function to clean up resources and detach the device from the operating system. Within this cleanup sequence, the code previously utilized cancel_delayed_work() to halt pending delayed work items associated with RGB lighting control, button input processing, and microcontroller initialization. This specific API call is designed solely to dequeue a scheduled work item if it has not yet started execution; however, it does not block or wait for any callback that is currently running on another CPU core or thread context.
This lack of synchronization creates a critical window where the driver proceeds with hardware shutdown procedures while background tasks are still actively accessing device resources. Specifically, after cancel_delayed_work() returns, the code immediately calls hid_hw_close and hid_hw_stop to disable communication with the USB HID device. If one of the delayed work callbacks—such as oxp_rgb_queue_fn for LED control, oxp_btn_queue_fn for button state reporting, or oxp_mcu_init_fn for firmware initialization—is executing at that exact moment, it retains a reference to the now-invalidated hardware interface. These functions continue to execute their logic and attempt to send commands or read data from the device through hid_hw_write or similar interfaces, unaware that the underlying transport layer has already been terminated by the removal routine.
The operational impact of this flaw is severe, as it leads to use-after-free conditions and potential kernel panics due to null pointer dereferences or invalid memory accesses. When a work callback attempts to interact with the HID device after hid_hw_stop has been called, the internal structures managing the USB endpoint communication may have already been freed or marked for deallocation by the core HID subsystem. This concurrency violation can result in data corruption within kernel memory spaces, unpredictable system behavior, or immediate crashes of the host machine. In security terms, this represents a classic race condition that could potentially be exploited to achieve arbitrary code execution if an attacker can control the timing and content of the delayed work items, although it primarily manifests as a stability issue under normal usage patterns involving hot-plugging devices or rapid driver unloading.
From a classification perspective, this vulnerability aligns with CWE-362, which describes concurrent execution using shared resources with improper synchronization. The failure to ensure mutual exclusion between the device teardown process and active worker threads allows for unsafe access to shared state. Furthermore, in the context of the MITRE ATT&CK framework, this type of flaw is relevant to techniques involving exploitation of race conditions during resource management, which can be leveraged to bypass security controls or cause denial of service against system stability. The root cause is not a logic error in the business rules but rather an incorrect API usage pattern that fails to respect the lifecycle constraints of kernel asynchronous work items relative to hardware state transitions.
The resolution involves replacing the non-blocking cancel_delayed_work() calls with cancel_delayed_work_sync(). This synchronous variant performs two critical actions: it first dequeues any pending, not-yet-started work items, and secondly, it blocks the calling thread until all currently executing instances of that specific delayed work callback have completed. By enforcing this synchronization point before proceeding to hid_hw_close and hid_hw_stop, the driver guarantees that no background task will attempt to access the HID device after its interface has been shut down. This ensures a clean and safe teardown sequence where hardware resources are only released once all dependent software activities have definitively ceased their interaction with them.
To mitigate similar issues in other drivers or future developments, engineers must rigorously audit the usage of asynchronous work APIs during resource cleanup sequences. It is essential to distinguish between canceling pending tasks that have not yet started and stopping active tasks that are currently running. Whenever a driver removes hardware dependencies, it must ensure that all associated kernel threads, timers, and delayed works are fully terminated before releasing references to those hardware structures. This includes verifying that the synchronization primitives used provide adequate blocking behavior to prevent race conditions between teardown logic and concurrent execution contexts. Adhering to these practices prevents use-after-free vulnerabilities and maintains system integrity during dynamic device management operations.