CVE-2026-74356 in Linux
Summary
by MITRE • 08/15/2026
In the Linux kernel, the following vulnerability has been resolved:
vhost: fix vhost_get_avail_idx for a non empty ring
vhost_get_avail_idx is supposed to report whether it has updated vq->avail_idx. Instead, it returns whether all entries have been consumed, which is usually the same. But not always - in drivers/vhost/net.c and when mergeable buffers have been enabled, the driver checks whether the combined entries are big enough to store an incoming packet. If not, the driver re-enables notifications with available entries still in the ring. The incorrect return value from vhost_get_avail_idx propagates through vhost_enable_notify and causes the host to livelock if the guest is not making progress, as vhost will immediately disable notifications and retry using the available entries.
This goes back to commit d3bb267bbdcb ("vhost: cache avail index in vhost_enable_notify()") which changed vhost_enable_notify() to compare the freshly read avail index against vq->last_avail_idx instead of the previously cached vq->avail_idx. Commit 7ad472397667 ("vhost: move smp_rmb() into vhost_get_avail_idx()") then carried over the same comparison when refactoring vhost_enable_notify() to call the unified vhost_get_avail_idx().
The obvious fix is to make vhost_get_avail_idx do what the comment says it does and report whether new entries have been added.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 08/16/2026
The vulnerability identified in the Linux kernel's vhost subsystem stems from a logical error within the function responsible for tracking available buffer indices, specifically affecting how notification states are managed between the host and guest virtual machines. The core issue resides in the implementation of vhost_get_avail_idx, which is designed to report whether new entries have been added to the virtqueue ring by checking if the current availability index has advanced beyond a previously cached value. However, due to an incorrect return condition introduced during previous refactoring efforts, the function erroneously reports success based on whether all available entries in the ring have been consumed rather than verifying if any new data has arrived from the guest. This semantic mismatch creates a critical flaw in the notification mechanism that governs how the host processes incoming network packets when mergeable buffers are enabled.
The operational impact of this defect is most severe in drivers such as vhost/net, where efficient packet processing relies on precise synchronization between the consumer and producer indices within the virtqueue ring. When mergeable buffers are active, the driver must evaluate whether the combined size of available entries is sufficient to accommodate an incoming network packet. If the buffer space is insufficient, the driver intentionally re-enables notifications while leaving some entries unconsumed in the ring, expecting that future packets will fill these slots or trigger further processing cycles. Because vhost_get_avail_idx incorrectly returns a value indicating that all entries are consumed despite available data remaining, this false positive propagates through vhost_enable_notify to the host's event loop logic. Consequently, the host misinterprets the state of the ring and immediately disables notifications under the assumption that no new work is pending.
This incorrect state management leads directly to a livelock condition when the guest fails to make progress or sends packets smaller than the threshold required for mergeable buffer processing. Since the host believes it has already processed all available data, it stops listening for further events from the virtqueue. However, because new entries may still be added by the guest that do not meet the size criteria for immediate consumption in a single pass, and notifications are disabled, these packets remain unprocessed indefinitely. The system enters a state where neither side makes forward progress: the host waits for notifications it has suppressed, and the guest continues to send data into a ring whose status is being misreported by the kernel logic. This results in network connectivity loss or severe performance degradation within the virtualized environment, effectively causing a denial of service for workloads relying on this specific configuration.
The root cause traces back to commit d3bb267bbdcb which initially altered vhost_enable_notify to compare against a freshly read availability index rather than the cached one, followed by commit 7ad472397667 which refactored this logic into the unified vhost_get_avail_idx function. During these changes, the return value semantics were not updated to match the new comparison strategy, leading to the persistent logical error where consumption status is conflated with arrival status. To resolve this issue, the implementation of vhost_get_avail_idx must be corrected to strictly adhere to its documented purpose: returning true only when new entries have genuinely been added to the ring since the last check. This ensures that notification states are accurately maintained and prevents the host from prematurely disabling event monitoring.
From a security perspective, while this is primarily a stability and availability issue rather than a direct privilege escalation or data exfiltration vector, it aligns with CWE-841 Improper Enforcement of Behavioral Workflow because the system fails to enforce the correct sequence of state transitions regarding buffer consumption and notification handling. It also relates to CWE-697 Incorrect Comparison due to the flawed logic determining whether progress has been made in processing queue entries. In terms of MITRE ATT&CK, this vulnerability could be leveraged by a malicious guest operating system or compromised virtual machine to induce resource exhaustion on the host through sustained livelock conditions, mapping towards T1496 Resource Hijacking where an attacker consumes computational resources and network throughput without completing useful work, thereby degrading service for other tenants sharing the same physical infrastructure. Mitigation requires applying kernel patches that correct the return logic in vhost_get_avail_idx to accurately reflect whether new data has arrived rather than merely checking if previous buffers were emptied.