CVE-2026-53373
mm/vma: do not try to unmap a VMA if mmap_prepare() invoked from mmap()
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.
INFO
Published Date :
July 19, 2026, 11:16 a.m.
Last Modified :
July 19, 2026, 11:16 a.m.
Remotely Exploit :
No
Source :
416baaa9-dc9f-4396-8d5f-8c081fb06d67
Affected Products
The following products are affected by CVE-2026-53373
vulnerability.
Even if cvefeed.io is aware of the exact versions of the
products
that
are
affected, the information is not represented in the table below.
No affected product recoded yet
Solution
- Apply the provided kernel patch.
- Update userland VMA tests.
- Rebuild and install the kernel.
References to Advisories, Solutions, and Tools
Here, you will find a curated list of external links that provide in-depth
information, practical solutions, and valuable tools related to
CVE-2026-53373.
| URL | Resource |
|---|---|
| https://git.kernel.org/stable/c/5394bcb746503f2ae4b206212416dccea78e3773 | |
| https://git.kernel.org/stable/c/619eab23e1ce7c97e54bfc5a417306d94b3f6f13 |
CWE - Common Weakness Enumeration
While CVE identifies
specific instances of vulnerabilities, CWE categorizes the common flaws or
weaknesses that can lead to vulnerabilities. CVE-2026-53373 is
associated with the following CWEs:
Common Attack Pattern Enumeration and Classification (CAPEC)
Common Attack Pattern Enumeration and Classification
(CAPEC)
stores attack patterns, which are descriptions of the common attributes and
approaches employed by adversaries to exploit the CVE-2026-53373
weaknesses.
We scan GitHub repositories to detect new proof-of-concept exploits. Following list is a collection of public exploits and proof-of-concepts, which have been published on GitHub (sorted by the most recently updated).
Results are limited to the first 15 repositories due to potential performance issues.
The following list is the news that have been mention
CVE-2026-53373 vulnerability anywhere in the article.
The following table lists the changes that have been made to the
CVE-2026-53373 vulnerability over time.
Vulnerability history details can be useful for understanding the evolution of a vulnerability, and for identifying the most recent changes that may impact the vulnerability's severity, exploitability, or other characteristics.
-
New CVE Received by 416baaa9-dc9f-4396-8d5f-8c081fb06d67
Jul. 19, 2026
Action Type Old Value New Value Added Affected [{'repo': 'https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git', 'vendor': 'Linux', 'product': 'Linux', 'versions': [{'status': 'affected', 'version': 'ac0a3fc9c07df79dc8a4ce9d274df00afc7bf12d', 'lessThan': '5394bcb746503f2ae4b206212416dccea78e3773', 'versionType': 'git'}, {'status': 'affected', 'version': 'ac0a3fc9c07df79dc8a4ce9d274df00afc7bf12d', 'lessThan': '619eab23e1ce7c97e54bfc5a417306d94b3f6f13', 'versionType': 'git'}], 'programFiles': ['include/linux/mm.h', 'mm/util.c', 'mm/vma.c', 'tools/testing/vma/include/dup.h', 'tools/testing/vma/include/stubs.h'], 'defaultStatus': 'unaffected'}, {'repo': 'https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git', 'vendor': 'Linux', 'product': 'Linux', 'versions': [{'status': 'affected', 'version': '6.19'}, {'status': 'unaffected', 'version': '0', 'lessThan': '6.19', 'versionType': 'semver'}, {'status': 'unaffected', 'version': '7.0.9', 'versionType': 'semver', 'lessThanOrEqual': '7.0.*'}, {'status': 'unaffected', 'version': '7.1', 'versionType': 'original_commit_for_fix', 'lessThanOrEqual': '*'}], 'programFiles': ['include/linux/mm.h', 'mm/util.c', 'mm/vma.c', 'tools/testing/vma/include/dup.h', 'tools/testing/vma/include/stubs.h'], 'defaultStatus': 'affected'}] Added 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. Added Reference https://git.kernel.org/stable/c/5394bcb746503f2ae4b206212416dccea78e3773 Added Reference https://git.kernel.org/stable/c/619eab23e1ce7c97e54bfc5a417306d94b3f6f13