GPU VulnDB

Database/Kernel, userspace & hypervisor

Linux kernel mm: mincore/MADV_PAGEOUT ownership checks use the wrong idmap on idmapped mounts

CVE-2026-64294Kernel, userspace & hypervisorcurated

Impact

The ownership check that gates the page-cache side-channel protection in mincore() and madvise(MADV_PAGEOUT) was evaluated against nop_mnt_idmap, so it ignored the mount's idmap entirely. On idmapped mounts, which is how container runtimes and user-namespace pods present shared images and volumes, that check decides against the on-disk owner rather than the translated one, so the policy the kernel enforces is not the policy it intends. Upstream describes the practical effect as usually benign, because the fallback file_permission(MAY_WRITE) does use the correct idmap and normally succeeds; the visible edge case is a mode-0444 file where neither check passes. The record shows no demonstrated cross-tenant page-cache leak, and the issue was found by code inspection rather than in the wild, so treat this as an isolation-semantics correctness fix on multi-tenant nodes, not an urgent one.

Who can reach it

Local unprivileged process calling mincore() or madvise(MADV_PAGEOUT) on a file reached through an idmapped mount, for example a tenant process inside a user-namespaced container. No authentication beyond having a shell or workload on the node.

What to do

Pick up the fixed stable kernel (commits at git.kernel.org) and reboot each node; the change is in mm, so there is no daemon-restart or live-patch path. Given the low practical impact, fold it into the next scheduled kernel rotation rather than a dedicated drain.

References

Related entries

All Kernel, userspace & hypervisor entries

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.