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… (CVE-2026-53373)
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.
AI Analysis
Technical Summary
The vulnerability in the Linux kernel concerns the mm/vma code path where the mmap_prepare() hook can be invoked from the mmap() hook of stacked drivers (e.g., overlayfs, shm). Previously, on error, the code attempted to unmap a VMA that was not fully established and already detached, causing warnings and potentially unstable behavior. The patch modifies the logic to detect whether the mmap action is completed via the compatibility layer or directly, and only attempts VMA cleanup in the direct case. This prevents unnecessary and problematic unmapping of detached VMAs.
Potential Impact
The vulnerability could cause kernel warnings and unstable behavior related to VMA management during mmap operations in stacked drivers. There is no indication of direct security impact such as privilege escalation or denial of service. No known exploits in the wild have been reported.
Mitigation Recommendations
A patch has been applied to the Linux kernel to address this issue. Users should update to a kernel version that includes this fix. Since this is a kernel-level fix, no additional mitigation steps are required beyond applying the official update.
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… (CVE-2026-53373)
Description
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.
CVSS v3.1
Score 7.8high
AI-Powered Analysis
Machine-generated threat intelligence
Technical Analysis
The vulnerability in the Linux kernel concerns the mm/vma code path where the mmap_prepare() hook can be invoked from the mmap() hook of stacked drivers (e.g., overlayfs, shm). Previously, on error, the code attempted to unmap a VMA that was not fully established and already detached, causing warnings and potentially unstable behavior. The patch modifies the logic to detect whether the mmap action is completed via the compatibility layer or directly, and only attempts VMA cleanup in the direct case. This prevents unnecessary and problematic unmapping of detached VMAs.
Potential Impact
The vulnerability could cause kernel warnings and unstable behavior related to VMA management during mmap operations in stacked drivers. There is no indication of direct security impact such as privilege escalation or denial of service. No known exploits in the wild have been reported.
Mitigation Recommendations
A patch has been applied to the Linux kernel to address this issue. Users should update to a kernel version that includes this fix. Since this is a kernel-level fix, no additional mitigation steps are required beyond applying the official update.
Technical Details
- Gcve Source
- db.gcve.eu
- Osv Id
- GHSA-vfrx-cq74-4pr7
- Osv Schema Version
- 1.4.0
- Aliases
- ["CVE-2026-53373"]
- Ecosystems
- []
- Database Specific Severity
- null
- Cvss Version
- 3.1
Threat ID: 6a5d27ae2a4a8d59891328a3
Added to database: 07/19/2026, 19:38:22 UTC
Last enriched: 07/19/2026, 20:25:19 UTC
Last updated: 09/03/2026, 10:52:10 UTC
Views: 89
Community Reviews
0 reviewsCrowdsource mitigation strategies, share intel context, and vote on the most helpful responses. Sign in to add your voice and help keep defenders ahead.
Want to contribute mitigation steps or threat intel context? Sign in or create an account to join the community discussion.
Actions
Updates to AI analysis require Pro Console access. Upgrade inside Console → Billing.
Need more coverage?
Upgrade to Pro Console for AI refresh and higher limits.
For incident response and remediation, OffSeq services can help resolve threats faster.
Latest Threats
Check if your credentials are on the dark web
Instant breach scanning across billions of leaked records. Free tier available.