CVE-2026-74713 in Linux
Summary
by MITRE • 08/22/2026
In the Linux kernel, the following vulnerability has been resolved:
vhost_iotlb: bound map allocation in add_range
vhost_iotlb_add_range_ctx() only retires an old entry when the table has a non-zero limit, has exactly reached that limit and has VHOST_IOTLB_FLAG_RETIRE set. Non-retiring tables can keep allocating entries after reaching their configured limit.
Existing vhost devices allocate their IOTLB with max_iotlb_entries from vhost.c, which defaults to 2048 and is tunable by module parameter. Use the caller-provided limit at the allocation point instead of adding a separate default in the common IOTLB helper, and reject non-positive values in vhost paths that can report an error.
Other vhost IOTLB users should not create zero-limit tables when entries can be populated from userspace or guest-controlled requests. Add caller-side max_iotlb_entries parameters for mlx5 vDPA, VDUSE and vhost-vDPA. Reject non-positive VDUSE and vhost-vDPA values, and require at least two entries for vdpa_sim and mlx5 vDPA paths that install full-range mappings, since those mappings are split into two IOTLB entries.
Handle full-range mappings in the common helper by checking that the IOTLB can hold both split entries before inserting the first half. This avoids returning an error after leaving a half mapping behind.
When the table is full, keep the existing retire behavior for retiring tables and return -ENOSPC for non-retiring tables. Reuse the retired map node instead of freeing it and allocating a replacement, so a stream of IOTLB updates cannot keep forcing GFP_ATOMIC allocations after the table has reached its limit. If a zero-limit IOTLB still reaches the common helper, treat it as a configuration error and return -EINVAL.
I found this bug myself, though the patch was written with AI assistance.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 08/22/2026
The vulnerability identified in the Linux kernel's vhost_iotlb subsystem represents a critical resource management flaw that allows for unbounded memory allocation under specific conditions. The core technical issue lies within the logic governing how IOTLB (Input/Output Translation Lookaside Buffer) entries are retired when the table reaches its configured capacity limit. Specifically, the function vhost_iotlb_add_range_ctx() was designed to retire old entries only if three strict conditions were met simultaneously: the table had a non-zero limit, it had exactly reached that limit, and the VHOST_IOTLB_FLAG_RETIRE flag was set. This logic created a dangerous edge case where tables configured without retirement capabilities or with specific flag configurations could continue allocating new map entries even after exceeding their intended maximum capacity. By failing to enforce hard limits on allocation for non-retiring tables, the system allowed an attacker or misconfigured guest virtual machine to exhaust kernel memory resources through continuous IOTLB updates.
From a security perspective, this flaw is classified under CWE-789: Memory Allocation with Excessive Size, as it permits uncontrolled resource consumption leading to potential denial of service conditions. The operational impact involves the exhaustion of kernel heap space via GFP_ATOMIC allocations, which are non-blocking and can lead to system instability or crashes if memory pressure becomes too severe. Furthermore, because vhost devices often handle data from userspace or guest-controlled requests, this vulnerability could be exploited remotely by a malicious virtual machine hoster or an attacker with access to the VM interface. The ability to force continuous allocations without proper cleanup not only consumes memory but also increases CPU overhead due to repeated allocation and deallocation cycles, degrading overall system performance for all running workloads on the affected hypervisor.
The remediation strategy implemented in this patch addresses these issues by enforcing stricter validation at multiple layers of the vhost stack. First, the common IOTLB helper was updated to reject non-positive limit values with an -EINVAL error code, treating them as configuration errors rather than allowing zero-limit tables that could bypass allocation checks entirely. Second, callers such as mlx5 vDPA, VDUSE, and vhost-vDPA were required to explicitly provide their own max_iotlb_entries parameters instead of relying on a hardcoded default in the common helper. This ensures that each device driver can define appropriate limits based on its specific operational requirements. Additionally, for paths like vdpa_sim and mlx5 vDPA that install full-range mappings which are split into two IOTLB entries, the code now requires at least two available slots before proceeding with insertion to prevent partial state corruption or resource leaks if an allocation fails mid-process.
To further mitigate the risk of memory exhaustion during high-frequency update scenarios, the patch modifies the behavior when the table is full. For non-retiring tables that reach their limit, the system now returns -ENOSPC instead of attempting new allocations, effectively blocking additional entries until space becomes available through other means. Crucially, for retiring tables, the implementation reuses retired map nodes rather than freeing and reallocating them. This optimization prevents a stream of IOTLB updates from forcing repeated GFP_ATOMIC allocations after the limit is reached, thereby reducing memory fragmentation and CPU overhead. These changes align with best practices outlined in CWE-400: Uncontrolled Resource Consumption, ensuring that resource limits are respected regardless of whether retirement flags are active or not.
The fix also incorporates defensive programming techniques to handle edge cases where zero-limit IOTLBs might still reach the common helper logic due to configuration oversights by developers. By explicitly checking for and rejecting these invalid configurations early in the process, the kernel prevents undefined behavior that could arise from attempting to manage a table with no defined capacity constraints. This approach reinforces the principle of least privilege and strict input validation within kernel subsystems handling guest interactions. The involvement of AI assistance in drafting the patch highlights modern development trends but does not diminish the necessity for rigorous manual review and testing, especially given the complexity of memory management logic in virtualization components.
In terms of industry standards mapping, this vulnerability relates to ATT&CK technique T1496: Resource Hijacking, where an adversary uses computing resources such as CPU or memory at a significant level that impacts normal system operations. The mitigation strategies employed here directly counteract this by enforcing hard limits on resource usage and ensuring proper cleanup procedures are followed during table updates. System administrators should ensure their kernels are updated to include these fixes, particularly if they run virtualized environments with untrusted guests or complex vhost configurations. Regular auditing of IOTLB configuration parameters across different vhost drivers is recommended to verify that appropriate limits are set and that no zero-limit tables exist in production deployments where guest-controlled inputs can trigger allocation requests.