CVE-2026-97987 in Linux
Summary
by MITRE • 09/25/2026
In the Linux kernel, the following vulnerability has been resolved:
virtio_input: reset device if input_register_device() fails
Probe marks the device DRIVER_OK with virtio_device_ready() before calling input_register_device(). If registration fails, the error path cleared vi->ready and called del_vqs() while the device was still live, so the device could keep DMA to queues that were already torn down.
Match remove/freeze: call virtio_reset_device() on that path before tearing down the virtqueues.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 09/25/2026
The Linux kernel vulnerability identified in the virtio_input subsystem involves a race condition and improper state management during device initialization, specifically when input_register_device fails. This issue stems from an incorrect sequence of operations within the probe function where the driver marks the virtual device as ready by calling virtio_device_ready before attempting to register the input device with the kernel's input subsystem. When registration succeeds, this ordering is benign; however, if input_register_device returns an error code indicating failure, the subsequent cleanup logic becomes problematic because it assumes the device has not yet been fully activated in a way that permits safe teardown without risking resource conflicts or hardware state inconsistencies.
The core technical flaw lies in how the driver handles the transition from initialization to operational status versus error recovery. By setting the DRIVER_OK flag via virtio_device_ready prior to confirming successful registration, the kernel considers the device live and potentially active for data transfer operations. If input_register_device fails due to issues such as memory allocation errors or conflicts with existing input handlers, the error path proceeds to clear the vi->ready flag and invokes del_vqs to destroy virtual queues. However, because the device was already marked as ready, there is a window where the virtio backend may still attempt to perform Direct Memory Access DMA operations against queue structures that are in the process of being torn down or have been deallocated. This mismatch between driver state reporting and actual resource availability creates a dangerous condition where stale pointers or active hardware contexts interact with freed memory regions.
The operational impact of this vulnerability is significant, primarily manifesting as kernel instability ranging from subtle data corruption to severe system crashes such as page faults or general protection faults. Since virtio devices often facilitate communication between the guest operating system and the hypervisor host, improper DMA operations can lead to memory safety violations within the kernel space. In virtualized environments, this could potentially allow for denial of service against the local instance by crashing the VM, or in more complex scenarios involving shared resources, it might expose mechanisms that could be leveraged for further exploitation if adjacent memory regions contain sensitive data. The lack of a proper reset mechanism means the device remains in an undefined state where it is neither fully initialized nor cleanly removed, complicating debugging and recovery efforts while leaving the system vulnerable to instability under load or during hot-plug events.
To mitigate this vulnerability, the fix implements a critical change by ensuring that virtio_reset_device is called on the error path before tearing down the virtual queues. This aligns the cleanup procedure with the remove and freeze operations, guaranteeing that any pending DMA transactions are halted and hardware state is neutralized before resources are released. From a security architecture perspective, this addresses CWE-362 Concurrent Execution using Shared Resource with Improper Synchronization by ensuring atomicity in state transitions during error handling. It also mitigates risks associated with CWE-416 Use After Free by preventing access to queue structures that are being destroyed while potentially still referenced by hardware DMA engines. Furthermore, the correction supports ATT&CK technique T1059 Command and Scripting Interpreter resilience by ensuring that driver-level failures do not leave the system in a compromised or unstable state that could be exploited for privilege escalation or persistence through kernel panic exploitation vectors. System administrators should ensure their kernels are updated to include this patch to maintain stability and security integrity within virtualized infrastructure environments relying on virtio input devices.