CVE-2026-74614 in Linux
Summary
by MITRE • 08/22/2026
In the Linux kernel, the following vulnerability has been resolved:
vsock/virtio: read virtqueues under worker locks
Commit bd50c5dc182b ("vsock/virtio: add support for device suspend/resume") made the *_run flags transition from false to true when restore installs replacement virtqueues. The RX, TX and event workers read their virtqueue before locking and checking the corresponding flag, so a worker delayed across freeze and restore can observe the replacement queue's running state while retaining a pointer to the deleted queue.
Read each virtqueue under its mutex after checking the run flag, keeping the pointer and state in the same queue generation.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 08/22/2026
The Linux kernel vulnerability identified within the vsock/virtio subsystem represents a critical race condition arising from improper synchronization during device suspend and resume operations. This issue was introduced by commit bd50c5dc182b, which added support for device power state transitions including suspend and resume functionality. The core of the flaw lies in how worker threads interact with virtual queues (virtqueues) when these structures are replaced or reinitialized during system restoration. Specifically, the RX, TX, and event workers access their respective virtqueue pointers before acquiring the necessary mutex locks to verify the operational status flags. This sequence creates a window where a delayed worker thread can observe that a replacement queue is marked as running while still holding a stale pointer to the previously deleted or invalidated queue structure.
From a technical perspective, this constitutes a use-after-free scenario combined with a race condition on shared data structures. When the system resumes from suspend, new virtqueues are installed and their associated run flags are set to true. However, because worker threads check these flags without holding the corresponding mutexes that protect the queue pointers, they may proceed to operate on memory regions that have already been freed or repurposed by other kernel processes managing the device lifecycle. This lack of atomicity between checking the operational state and accessing the underlying data structure allows for inconsistent states where logical execution flow diverges from physical memory safety. The worker retains a reference to an obsolete queue object, leading to potential memory corruption, undefined behavior, or system crashes when it attempts to process packets using invalid pointers.
The operational impact of this vulnerability is severe, potentially allowing local attackers with access to the virtualized environment to trigger denial-of-service conditions by causing kernel panics through crafted suspend-resume cycles. In more sophisticated attack scenarios, if an attacker can control the timing or content of the virtqueue operations during these transitions, they might exploit the use-after-free condition to achieve arbitrary code execution within the kernel space. This compromises the integrity and availability of the host system running the virtual machine. The vulnerability affects systems utilizing vsock over virtio transports where power management features are enabled, making it relevant for a wide range of cloud infrastructure and desktop virtualization deployments that rely on dynamic resource allocation and power saving states.
Mitigation strategies primarily involve applying the upstream kernel patch which corrects the locking order to ensure thread safety during state transitions. The fix mandates reading each virtqueue under its associated mutex after verifying the run flag, thereby ensuring that the pointer and operational state remain consistent within a single queue generation context. This change enforces strict serialization of access to critical data structures during suspend and resume events. Administrators should update their Linux kernels to versions containing this commit or apply vendor-specific patches if available. Additionally, disabling device suspend/resume features in environments where such vulnerabilities are deemed unacceptable can serve as an immediate workaround until full patching is implemented. Regular security audits focusing on kernel concurrency patterns and adherence to established standards like CWE-362 for race conditions and CWE-416 for use-after-free errors are recommended to prevent similar synchronization flaws in future development cycles.