The Linux kernel introduced an issue in which file ownership checks performed by the mm subsystem used the nop_mnt_idmap instead of the correct mount‑specific idmap. This caused owner_or_capable() evaluations to fail when a file owned by one UID on disk was translated to a different UID via an idmapped mount, potentially denying legitimate access. Although the case is described as benign for normal memory page‑out operations, it creates a serious flaw where operations requiring correct permission checks may fail, exposing the system to denial‑of‑service or privilege‑escalation vectors. The vulnerability arises from improper handling of ID mappings, resulting in an inconsistent enforcement of file ownership semantics. This flaw corresponds to CWE‑283 (Improper Access Control).

All Linux kernel installations that have not incorporated the patch commit for this issue are vulnerable. This includes the stock kernel across major distributions where the relevant code paths are compiled, as the changes affect the generic mm layer. Exact affected kernel versions are not specified in the advisory, but any release prior to the commit that introduced the file_owner_or_capable() fix remains at risk.

The EPSS score is less than 1%, indicating a very low predicted exploitation probability. The vulnerability is not listed in the CISA KEV catalog. The likely attack vector requires the attacker to have the ability to create or manipulate idmapped mounts, which typically necessitates kernel‑level or root privilege. Once that capability is available, the attacker could force failed authorization checks on files whose ownership differs by idmap translation, potentially disrupting legitimate operations or extracting privileged access. The practical risk is mitigated by the low EPSS and the requirement of elevated privileges, yet still presents a non‑negligible threat in high‑security environments.