CVE-2026-64292 in Linux
Summary
by MITRE • 07/25/2026
In the Linux kernel, the following vulnerability has been resolved:
iommufd: Move vevent memory allocation outside spinlock
The veventq memory allocation happens inside the spinlock. Given its depth is decided by the user space, this leaves a vulnerability, where userspace can allocate large queues to exhaust atomic memory reserves.
Move the allocation outside the spinlock and use GFP_NOWAIT, which can fail fast under memory pressure without dipping into the GFP_ATOMIC reserves or direct-reclaiming from the threaded IRQ handler. On allocation failure, queue the lost_events_header (so userspace learns of the drop) and return -ENOMEM so the caller learns of the kernel-side memory pressure.
This is intentionally distinct from the queue-overflow path, which also queues the lost_events_header but returns 0: a full queue is an expected userspace-pacing condition rather than a kernel error.
A subsequent change will cap the upper bound of the veventq_depth.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 07/25/2026
The vulnerability identified in the Linux kernel relates to improper memory management within the iommufd subsystem, specifically concerning how virtual event queue memory allocation is handled during concurrent operations. This issue stems from the placement of memory allocation routines inside a spinlock context, creating a potential denial-of-service scenario that can be exploited by malicious or malformed user-space processes. The technical flaw manifests when user-space applications specify large queue depths, causing the kernel to allocate substantial memory resources while holding the spinlock, which prevents other concurrent operations from proceeding and potentially leading to system-wide resource exhaustion.
The core problem lies in the spinlock protection mechanism that governs access to virtual event queue operations. When the veventq memory allocation occurs within the spinlock, it creates a critical performance bottleneck where kernel threads become blocked for extended periods while waiting for memory allocation. This scenario is particularly dangerous because user-space applications can specify arbitrary queue depths, allowing them to consume excessive atomic memory reserves that should remain available for critical kernel operations. The vulnerability represents a classic resource exhaustion attack vector where the attacker leverages legitimate kernel interfaces to consume system resources in an unpredictable and potentially catastrophic manner.
The operational impact of this vulnerability extends beyond simple performance degradation to include potential system instability and complete denial-of-service conditions. During high-concurrency scenarios or when memory pressure exists, the spinlock contention caused by large queue allocations can prevent other kernel subsystems from functioning correctly. The memory allocation behavior within the spinlock context also prevents the kernel from utilizing normal memory management mechanisms that would otherwise handle allocation failures gracefully. This creates a situation where legitimate kernel operations are starved of resources while malicious processes systematically consume available memory through controlled queue depth manipulation.
The mitigation strategy implemented addresses this vulnerability by moving the vevent memory allocation outside the spinlock protection, thereby reducing the time spent holding critical synchronization primitives. The solution employs GFP_NOWAIT flags which enable immediate allocation attempts without entering potentially problematic kernel memory management paths that could lead to direct-reclaiming from threaded IRQ handlers or exhaustion of atomic reserves. When allocation fails under these conditions, the system properly handles the error by queuing lost events headers to notify user-space applications of dropped events while returning -ENOMEM to indicate kernel-side memory pressure. This approach maintains the fundamental integrity of event delivery while preventing resource exhaustion attacks that could compromise system stability.
This vulnerability aligns with several cybersecurity principles and threat modeling frameworks including CWE-400, which addresses unrestricted resource consumption, and represents a classic example of improper resource management in kernel space operations. The mitigation strategy follows established best practices for kernel memory allocation under concurrency constraints and demonstrates proper error handling procedures that prevent cascading failures. The solution also incorporates elements of the ATT&CK framework's privilege escalation tactics by ensuring that user-space actions cannot be leveraged to compromise kernel stability through resource exhaustion attacks.
The implementation of this fix represents a significant improvement in kernel robustness and memory management practices within the iommufd subsystem. By separating memory allocation from spinlock protection, the kernel maintains better responsiveness under load while preventing malicious userspace applications from exploiting the allocation timing to cause system instability. The distinction between allocation failure handling for memory pressure versus queue overflow conditions ensures that legitimate user-space pacing behavior is not confused with actual system errors, maintaining proper operational semantics while improving overall system resilience against resource exhaustion attacks.
The subsequent change mentioned in the fix documentation to cap the upper bound of veventq_depth further strengthens the security posture by implementing explicit limits on user-space control over kernel memory allocation. This additional layer of protection prevents any potential edge cases where even the improved allocation strategy might be bypassed, ensuring that kernel memory usage remains within predictable and manageable bounds regardless of user-space input parameters. The comprehensive nature of this fix demonstrates a mature understanding of both the immediate technical problem and its broader implications for system security and reliability.