CVE-2026-53373
Is CVE-2026-53373 real, exploitable, or a false positive? Here's the community verdict.
signals
public sources
High CVSS base score, but low real-world exploitation probability (EPSS). Likely less urgent than the score implies.
baseline read
auto · not a community verdict
Real, but low real-world risk
A genuine vulnerability on paper, but EPSS shows little real-world exploitation — the base score may overstate urgency. This is not the same as a false positive.
Based on CVSS · FIRST EPSS
Confirm or dispute →CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
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.
References
Published
Embed this verdict
[](https://www.truepositive.app/cve/CVE-2026-53373)<a href="https://www.truepositive.app/cve/CVE-2026-53373"><img src="https://www.truepositive.app/cve/CVE-2026-53373/badge.svg" alt="TruePositive verdict for CVE-2026-53373"></a>Live badge that updates automatically as the community verdict changes.
Community ground truth
Be the first practitioner to weigh in
So far this is only TruePositive's editorial baseline from public sources. Add your real-world verdict below — it becomes the signal the next person triaging this relies on.
🥇 The first 50 practitioners to contribute earn a Founding Contributor badge.
In your experience, is this finding real and exploitable?
awaiting field verdictsCurated baseline: A curated baseline from public sources, shown separately from community verdicts.
No account needed. Anonymous verdicts post as an unverified signal. Log in to make yours verified and earn reputation.
Field notes & remediation
Verdicts are the quick signal. Notes are the evidence and fixes behind them.
- 0
This scores high on paper (CVSS 7.8) but the real-world signal is low. It is not in CISA KEV and no public exploit was found, and near-term exploitation looks unlikely (EPSS about 0%). Verify your own exposure before treating it as urgent. It needs local access, so it reads more as a privilege-escalation or post-access risk than a remote one. Not an emergency for most teams, but patch it in your normal cycle and check whether the affected component is actually exposed in your setup.