Instituto Nacional de ciberseguridad. Sección Incibe
Instituto Nacional de Ciberseguridad. Sección INCIBE-CERT

CVE-2026-64294

Gravedad:
Pendiente de análisis
Tipo:
No Disponible / Otro tipo
Fecha de publicación:
25/07/2026
Última modificación:
25/07/2026

Descripción

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm: do file ownership checks with the proper mount idmap<br /> <br /> Ever since idmapped mounts were introduced, inode ownership checks (for<br /> side-channel protection) in mincore() and madvise(MADV_PAGEOUT) were done<br /> against the nop_mnt_idmap, which completely ignores the file&amp;#39;s mount&amp;#39;s<br /> idmap. This results in odd edgecases like:<br /> <br /> 1) mount/bind-mount with an idmap userA:userB:1<br /> 2) userB runs an owner_or_capable() check on file that is owned by userA<br /> on-disk/in-memory, but owned by userB after idmap translation<br /> 3) owner_or_capable() mysteriously fails as the correct idmap wasn&amp;#39;t supplied<br /> <br /> In the case of mincore/madvise MADV_PAGEOUT, this is usually benign,<br /> because file_permission(file, MAY_WRITE) will probably succeed, as it uses<br /> the proper idmap internally, but it does not need to be the case on e.g a<br /> 0444 file where even the owner itself doesn&amp;#39;t have permissions to write to<br /> it.<br /> <br /> Since this is clearly not trivial to get right, introduce a<br /> file_owner_or_capable() that can carry the correct semantics, and switch<br /> the various users in mm to it.<br /> <br /> The issue was found by manual code inspection &amp; an off-list discussion<br /> with Jan Kara.

Impacto