CVE-2026-64294: Linux Kernel Privilege Escalation Flaw

CVE-2026-64294 Overview

CVE-2026-64294 affects the Linux kernel memory management (mm) subsystem. Inode ownership checks used for side-channel protection in mincore() and madvise(MADV_PAGEOUT) were performed against nop_mnt_idmap instead of the file's actual mount idmap. This flaw has existed since idmapped mounts were introduced. On idmapped bind mounts, owner_or_capable() decisions rely on pre-translation ownership, producing incorrect permission outcomes on files where the owner lacks write permission (for example, mode 0444). The issue was found through manual code inspection and an off-list discussion with Jan Kara.

Critical Impact
Incorrect ownership evaluation on idmapped mounts can permit unintended callers to influence page cache residency and force page-out on files they do not properly own, weakening side-channel protections.

Affected Products

Linux kernel versions containing idmapped mount support prior to the fix commits
Linux stable branches referenced by commits 04ba248, 5c942ad, 744b23a, 8344bdf, and e187bc0
Distributions shipping the affected mm/mincore.c and mm/madvise.c code paths

Discovery Timeline

2026-07-25 - CVE-2026-64294 published to NVD
2026-07-30 - Last updated in NVD database

Technical Details for CVE-2026-64294

Vulnerability Analysis

The defect is a kernel logic error in the mm subsystem. mincore() reports page cache residency, and madvise(MADV_PAGEOUT) evicts pages from the cache. Both operations previously performed side-channel access checks using owner_or_capable() with nop_mnt_idmap, which ignores any idmap associated with the file's mount. When a filesystem is mounted or bind-mounted with an idmap such as userA:userB:1, on-disk ownership differs from the effective ownership visible to callers through the idmapped mount. The check therefore evaluates the wrong identity relationship, and the outcome does not match the file's real access semantics under the mount.

Root Cause

The root cause is passing nop_mnt_idmap to inode ownership helpers rather than the mount's actual idmap. The mm code paths lacked a helper that consistently retrieved the correct idmap from the struct file. The fix introduces file_owner_or_capable(), which carries the file's mount context, and switches mincore() and madvise(MADV_PAGEOUT) callers to it. This is a kernel file-system permission handling flaw and falls under improper access control on idmapped mounts.

Attack Vector

A local user operating on an idmapped bind mount can invoke mincore() or madvise(MADV_PAGEOUT) against a file where the pre-translation on-disk owner differs from the post-translation caller identity. The check against nop_mnt_idmap produces a decision inconsistent with the actual mount idmap. On a 0444 file, the fallback file_permission(file, MAY_WRITE) also fails, so the incorrect ownership evaluation can gate operations that should be denied or should be allowed. Exploitation requires local access and an idmapped mount configuration; no network vector applies. See the Kernel Git Commit 04ba248 for the corrective change.

No verified public proof-of-concept code exists for this issue. Refer to the upstream commits for the precise code changes in mm/mincore.c and mm/madvise.c.

Detection Methods for CVE-2026-64294

Indicators of Compromise

No specific host or network indicators of compromise are published for this kernel logic flaw.
Unexpected use of madvise(MADV_PAGEOUT) against files not owned by the calling user on idmapped bind mounts.
Anomalous mincore() invocations from unprivileged processes targeting files across idmapped mount boundaries.

Detection Strategies

Inventory running kernels and compare against the fixed stable versions referenced by commits 04ba248, 5c942ad, 744b23a, 8344bdf, and e187bc0.
Audit systems for idmapped bind-mount configurations, container runtimes, and user-namespace tooling that create translated ownership views.
Use kernel auditing (auditd) rules on madvise and mincore syscalls to capture caller UID and target file path for later review.

Monitoring Recommendations

Forward auditd and syscall telemetry to a centralized data lake for cross-host correlation of unusual madvise and mincore patterns.
Track kernel package versions across the fleet and alert on hosts running unpatched builds.
Monitor container and namespace creation events that establish idmapped mounts, and correlate with subsequent mm syscall activity.

How to Mitigate CVE-2026-64294

Immediate Actions Required

Apply the vendor kernel update that includes file_owner_or_capable() and the switch of mincore() and madvise(MADV_PAGEOUT) to the proper mount idmap.
Prioritize patching on hosts using idmapped mounts, user namespaces, and container runtimes that rely on ID translation.
Reboot patched systems to load the fixed kernel image, since livepatch coverage for this change varies by distribution.

Patch Information

The upstream fix introduces file_owner_or_capable() and updates the mm callers. Reference commits: Kernel Git Commit 04ba248, Kernel Git Commit 5c942ad, Kernel Git Commit 744b23a, Kernel Git Commit 8344bdf, and Kernel Git Commit e187bc0.

Workarounds

Avoid using idmapped bind mounts for workloads that share files across UID ranges until patched kernels are deployed.
Restrict local user access on multi-tenant hosts and enforce least privilege on containers that mount host filesystems.
Where feasible, disable or constrain MADV_PAGEOUT usage from untrusted workloads through seccomp policies.

bash

# Verify running kernel and check for the fixed commits in the changelog
uname -r
rpm -q --changelog kernel | grep -E "04ba248|5c942ad|744b23a|8344bdf|e187bc0" || \
  dpkg-query -W -f='${Version}\n' linux-image-$(uname -r)

# Example seccomp restriction snippet (conceptual) to block MADV_PAGEOUT
# in an untrusted container profile
# {"syscalls":[{"names":["madvise"],"action":"SCMP_ACT_ERRNO","args":[{"index":2,"op":"SCMP_CMP_EQ","value":21}]}]}