CVE-2026-53373 in Linux
Summary
by MITRE • 07/19/2026
In the Linux kernel, the following vulnerability has been resolved:
mm/vma: do not try to unmap a VMA if mmap_prepare() invoked from mmap()
The mmap_prepare hook functionality includes the ability to invoke mmap_prepare() from the mmap() hook of existing 'stacked' drivers, that is ones which are capable of calling the mmap hooks of other drivers/file systems (e.g. overlayfs, shm).
As part of the mmap_prepare action functionality, we deal with errors by unmapping the VMA should one arise. This works in the usual mmap_prepare case, as we invoke this action at the last moment, when the VMA is established in the maple tree.
However, the mmap() hook passes a not-fully-established VMA pointer to the caller (which is the motivation behind the mmap_prepare() work), which is detached.
So attempting to unmap a VMA in this state will be problematic, with the most obvious symptom being a warning in vma_mark_detached(), because the VMA is already detached.
It's also unncessary - the mmap() handler will clean up the VMA on error.
So to fix this issue, this patch propagates whether or not an mmap action is being completed via the compatibility layer or directly.
If the former, then we do not attempt VMA cleanup, if the latter, then we do.
This patch also updates the userland VMA tests to reflect the change.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 07/19/2026
The vulnerability resides in the linux kernel's memory management subsystem particularly within the virtual memory area handling logic. This issue affects the interaction between mmap_prepare and mmap hooks when dealing with stacked filesystem drivers such as overlayfs and shared memory implementations. The core problem emerges from the improper handling of virtual memory area cleanup during error conditions when the mmap_prepare function is invoked from within the mmap hook context.
The technical flaw stems from a fundamental mismatch in VMA state management. When mmap_prepare() is called from within the mmap() hook of stacked drivers, it operates on a VMA that has not yet been fully established in the kernel's memory management structures. The VMA pointer passed to the mmap() hook is in a detached state, meaning it exists outside the normal maple tree data structure where VMA tracking occurs. During error handling, the system attempts to unmap this already-detached VMA, which triggers the vma_mark_detached() warning mechanism and creates inconsistent memory management states.
This vulnerability represents a specific case of improper resource cleanup that could lead to kernel instability and potential information disclosure. The flaw manifests when error conditions occur during mmap operations with stacked filesystems, where the cleanup logic attempts to operate on VMA structures that are in an intermediate or invalid state. According to CWE classification, this corresponds to CWE-457: Use of Uninitialized Variable, though more specifically it involves improper handling of detached memory management structures.
The operational impact of this vulnerability extends beyond simple kernel warnings to potentially destabilizing the memory management subsystem. When stacked filesystem drivers invoke mmap_prepare from within their mmap hooks, the system may exhibit unexpected behavior during error recovery paths. This could result in inconsistent kernel states where VMA cleanup operations attempt to modify structures that are already in an invalid state, potentially leading to memory leaks or more serious kernel crashes.
The fix implements a contextual awareness mechanism that determines whether mmap operations are being completed through the compatibility layer or directly. This patch introduces state tracking that prevents VMA cleanup attempts when the operation originates from the compatibility layer context, where cleanup is handled automatically by the calling mmap() handler. The solution aligns with ATT&CK framework concept T1068: Exploitation for Privilege Escalation by ensuring proper kernel memory management during privilege operations.
The mitigation approach addresses the root cause by establishing clear boundaries between different execution contexts within the memory management subsystem. This prevents the double cleanup scenario where both the compatibility layer and direct operation paths attempt to manage the same VMA resources. The userland test updates ensure that the new behavior is properly validated and that error conditions in stacked filesystem operations are handled correctly without triggering kernel warnings.
Security implications of this vulnerability extend to potential denial-of-service attacks that could destabilize kernel memory management or information disclosure through inconsistent state handling. The patch specifically targets the interaction between layered filesystem drivers and memory management hooks, making it particularly relevant for systems using overlayfs or similar stacked filesystem implementations where multiple filesystem layers can interact during memory mapping operations.