Skip to main content

Linux Kernel CVE-2026-53373

| EUVDEUVD-2026-45446 HIGH
2026-07-19 Linux GHSA-vfrx-cq74-4pr7
7.8
CVSS 3.1 · Vendor: Linux
Share

Severity by source

Vendor (Linux) PRIMARY
7.8 HIGH
AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
vuln.today AI
2.5 LOW

Local low-priv user (AV:L/PR:L) must reach a stacked-driver mmap error path (AC:H); observable impact is a warning/instability, so availability-low and no confirmed C/I impact.

3.1 AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:L
4.0 AV:L/AC:H/AT:N/PR:L/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N
SUSE
6.3 MEDIUM
AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:H/A:H
Red Hat
5.5 MEDIUM
qualitative

Primary rating from Vendor (Linux).

CVSS VectorVendor: Linux

Attack Vector
Local
Attack Complexity
Low
Privileges Required
Low
User Interaction
None
Scope
Unchanged
Confidentiality
High
Integrity
High
Availability
High

Lifecycle Timeline

5
Analysis Generated
Jul 20, 2026 - 18:01 vuln.today
CVSS changed
Jul 20, 2026 - 15:22 NVD
7.8 (HIGH)
Patch available
Jul 19, 2026 - 13:02 EUVD
CVE Published
Jul 19, 2026 - 10:01 cve.org
UNKNOWN (no severity yet)
CVE Published
Jul 19, 2026 - 10:01 cve.org
HIGH 7.8

DescriptionCVE.org

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.

AnalysisAI

Improper error handling in the Linux kernel's memory management VMA subsystem (mm/vma) allows a local low-privileged user to trigger a kernel warning and potential instability when an mmap() error path attempts to unmap an already-detached VMA. The flaw affects the mmap_prepare hook compatibility layer used by 'stacked' drivers such as overlayfs and shm in Linux 6.19 (and related stable branches), where a not-fully-established VMA pointer is passed to the caller. No public exploit identified at time of analysis; EPSS is low (0.14%, 4th percentile), and it is not on CISA KEV, indicating a robustness/correctness fix rather than an actively exploited weakness despite the high NVD CVSS score.

Technical ContextAI

The vulnerability lives in the Linux kernel's virtual memory area (VMA) management, specifically the mmap_prepare hook mechanism that lets stacked drivers (overlayfs, shm) invoke the mmap hooks of underlying drivers/filesystems. In the normal mmap_prepare flow, error cleanup unmaps the VMA at the last moment once it is established in the maple tree. However, when mmap_prepare() is invoked from a driver's mmap() hook, the VMA passed to the caller is detached and not fully established, so attempting to unmap it drives vma_mark_detached() to warn because the VMA is already detached. The fix propagates whether the action completes via the compatibility layer or directly, skipping cleanup in the former case since the mmap() handler already cleans up on error. CWE is not assigned (N/A) in the source data, but the root cause is an error-handling/state-consistency defect on a failure path; the CPE data identifies the generic vendor/product 'cpe:2.3:a:linux:linux' with no bounded version range.

RemediationAI

Upstream fix available (PR/commit); released patched version not independently confirmed - apply the kernel update containing commits 5394bcb746503f2ae4b206212416dccea78e3773 and 619eab23e1ce7c97e54bfc5a417306d94b3f6f13, which map to fixed builds referenced as 7.0.9 and 7.1 in the EUVD data. In practice, upgrade to the latest stable/distribution kernel that incorporates these commits (verify via https://git.kernel.org/stable/c/5394bcb746503f2ae4b206212416dccea78e3773 and https://git.kernel.org/stable/c/619eab23e1ce7c97e54bfc5a417306d94b3f6f13) and reboot to load the patched kernel. Because the trigger involves stacked drivers, an interim compensating control is to limit use of overlayfs and shm-backed mmap paths by unprivileged users where feasible - for example restricting unprivileged user namespaces / unprivileged overlayfs mounts (e.g. kernel.unprivileged_userns_clone=0 or distro-equivalent) to reduce reachability; the trade-off is that container runtimes and rootless workflows relying on unprivileged overlayfs will break, so validate against your workloads before enforcing. Given low EPSS and no active exploitation, scheduling the kernel patch through normal maintenance is reasonable rather than emergency patching.

Vendor StatusVendor

SUSE

Severity: Moderate
Product Status
SUSE Linux Enterprise Desktop 15 SP7 Not-Affected
SUSE Linux Enterprise Desktop 15 SP7 Not-Affected
SUSE Linux Enterprise High Availability Extension 15 SP7 Not-Affected
SUSE Linux Enterprise High Availability Extension 15 SP7 Not-Affected
SUSE Linux Enterprise High Availability Extension 16.0 Not-Affected

Share

CVE-2026-53373 vulnerability details – vuln.today

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy