Skip to main content

Linux Kernel CVE-2026-64294

| EUVDEUVD-2026-49006 MEDIUM
2026-07-25 Linux GHSA-rgg7-9234-2h22
Information Disclosure Linux
5.5
CVSS 3.1 · NVD
Share

Severity by source

NVD PRIMARY
5.5 MEDIUM
AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
vuln.today AI
5.5 MEDIUM

Local access and low-privilege account required; idmapped mount configuration is a prerequisite; no confidentiality or integrity impact; availability high from incorrectly denied memory management operations.

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

Primary rating from NVD.

CVSS VectorNVD

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

Lifecycle Timeline

5
Analysis Generated
Aug 12, 2026 - 15:09 vuln.today
CVSS changed
Aug 12, 2026 - 15:07 NVD
5.5 (MEDIUM)
Patch available
Jul 25, 2026 - 11:18 EUVD
CVE Published
Jul 25, 2026 - 08:49 nvd
MEDIUM 5.5
CVE Published
Jul 25, 2026 - 08:49 cve.org
UNKNOWN (no severity yet)

DescriptionNVD

In the Linux kernel, the following vulnerability has been resolved:

mm: do file ownership checks with the proper mount idmap

Ever since idmapped mounts were introduced, inode ownership checks (for side-channel protection) in mincore() and madvise(MADV_PAGEOUT) were done against the nop_mnt_idmap, which completely ignores the file's mount's idmap. This results in odd edgecases like:

  1. mount/bind-mount with an idmap userA:userB:1
  2. userB runs an owner_or_capable() check on file that is owned by userA

on-disk/in-memory, but owned by userB after idmap translation

  1. owner_or_capable() mysteriously fails as the correct idmap wasn't supplied

In the case of mincore/madvise MADV_PAGEOUT, this is usually benign, because file_permission(file, MAY_WRITE) will probably succeed, as it uses the proper idmap internally, but it does not need to be the case on e.g a 0444 file where even the owner itself doesn't have permissions to write to it.

Since this is clearly not trivial to get right, introduce a file_owner_or_capable() that can carry the correct semantics, and switch the various users in mm to it.

The issue was found by manual code inspection & an off-list discussion with Jan Kara.

AnalysisAI

Incorrect idmap handling in the Linux kernel memory management subsystem causes owner_or_capable() checks inside mincore() and madvise(MADV_PAGEOUT) to use the identity no-op mount idmap (nop_mnt_idmap) rather than the actual mount's idmap, producing incorrect ownership evaluations on idmapped mounts. Local users with low privileges on Linux 5.12+ systems configured with idmapped mounts may trigger incorrect authorization decisions that deny legitimate memory management operations, with the most impactful edge case occurring on 0444 files where neither the idmap check nor the fallback file_permission(MAY_WRITE) path succeeds. No public exploit is known and EPSS is 0.21% (11th percentile), reflecting minimal real-world exploitation risk despite the Linux kernel's ubiquitous deployment footprint.

Technical ContextAI

The Linux kernel memory management subsystem (mm/mincore.c, mm/madvise.c) performs file ownership checks via owner_or_capable(). Idmapped mounts, introduced in Linux 5.12 (starting at commit 9caccd41541a6f7d6279928d9f971f6642c361af), allow UID/GID remapping at the VFS layer - files owned by userA on disk appear owned by userB when accessed through a mount configured with the appropriate idmap. The defect is that mincore() and madvise(MADV_PAGEOUT) pass nop_mnt_idmap (the identity/no-op idmap structure that performs no translation) to owner_or_capable() instead of extracting and using the actual mount's idmap. Consequently the UID comparison is performed against on-disk ownership rather than idmap-translated ownership, causing legitimate idmap owners to fail the check. The fix introduces a file_owner_or_capable() helper that correctly derives the mount's idmap from the file structure before performing ownership comparisons. Affected CPE is cpe:2.3:a:linux:linux:*:*:*:*:*:*:*:* across versions since 5.12. No CWE was formally assigned; the root cause is an access control logic error most closely analogous to CWE-863 (Incorrect Authorization) or CWE-284 (Improper Access Control).

RemediationAI

The primary remediation is to apply the vendor-released kernel stable patches: upgrade to Linux 6.6.145, 6.12.96, 6.18.39, 7.1.4, or 7.2-rc3 or later, selecting the branch appropriate to the deployed kernel series. Patch commits are published at https://git.kernel.org/stable/c/744b23aa430d52f5c8e4dbff7d71496d6643bed2, https://git.kernel.org/stable/c/8344bdf0629457e532797b42d9d2bbf2a2900bbf, https://git.kernel.org/stable/c/5c942ad7df75925ee166e7f0fb36892d8dde376b, https://git.kernel.org/stable/c/04ba248d02d9eaa3d9077b00a6134caa75fa3e90, and https://git.kernel.org/stable/c/e187bc02f8fa4226d62814592cf064ee4557c470. As an interim compensating control, environments that do not require idmapped mounts can eliminate the attack surface entirely by not configuring them - this has no operational impact on systems that do not use container-layer UID remapping. On systems where idmapped mounts are required (e.g., rootless container runtimes), restricting which users can invoke madvise(MADV_PAGEOUT) via seccomp filtering or LSM policy (AppArmor/SELinux) reduces exposure, though this may affect container memory management performance. Distribution-specific kernel packages from major Linux vendors (RHEL, Ubuntu, SUSE) should be monitored for backported fixes if direct kernel compilation is not feasible.

Same technique Information Disclosure

View all
CVE-2019-2725 CRITICAL POC
9.8
CVE-2021-34523 CRITICAL POC
9.0
CVE-2013-2251 CRITICAL POC
9.8
CVE-2017-5638 CRITICAL POC
9.8
CVE-2025-24813 CRITICAL POC
9.8
CVE-2015-1701 HIGH POC
7.8
CVE-2017-0147 HIGH POC
7.5
CVE-2014-6324 HIGH POC
8.8

Vendor StatusVendor

SUSE

Severity: Moderate
Product Status
openSUSE Tumbleweed Fixed
SUSE Linux Enterprise Desktop 15 SP7 Affected
SUSE Linux Enterprise Desktop 15 SP7 Affected
SUSE Linux Enterprise High Availability Extension 15 SP7 Affected
SUSE Linux Enterprise High Availability Extension 15 SP7 Affected

Share

CVE-2026-64294 vulnerability details – vuln.today
Back

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