CVE-2026-74595 in Linux
Summary
by MITRE • 08/22/2026
In the Linux kernel, the following vulnerability has been resolved:
fscrypt: use the mount idmap for the owner check in fscrypt_ioctl_set_policy()
fscrypt_ioctl_set_policy() calls inode_owner_or_capable() with &nop_mnt_idmap before allowing an encryption policy to be set, instead of the idmap of the mount the ioctl was issued on.
fscrypt is used by filesystems that support idmapped mounts (e.g. ext4, f2fs), so on such a mount this compares the caller's fsuid against the unmapped on-disk owner rather than the mapped owner: the actual owner can be wrongly denied with -EACCES and an unrelated caller wrongly allowed. Use file_mnt_idmap(filp) instead.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 08/22/2026
The Linux kernel vulnerability identified in this advisory relates to a critical identity mapping error within the fscrypt subsystem, specifically affecting the ioctl interface used for setting encryption policies on files. The core technical flaw resides in the function fscrypt_ioctl_set_policy(), which is responsible for validating whether the calling process has sufficient privileges to modify the file's encryption settings. Historically, this validation step invoked inode_owner_or_capable() using a static nop_mnt_idmap structure rather than retrieving and utilizing the mount idmap associated with the specific filesystem instance where the ioctl was executed. This oversight creates a significant discrepancy between the security context perceived by the kernel during privilege checks and the actual identity mapping established for that particular mount point, leading to incorrect access control decisions in environments leveraging idmapped mounts.
Idmapped mounts are a feature introduced to support user namespace isolation, allowing filesystems like ext4 and f2fs to map external user identifiers to internal ones securely. When such a mount is active, the kernel translates between the mapped view of users visible to applications and the actual on-disk ownership metadata stored in the inode structures. By using nop_mnt_idmap, which performs no translation, the validation logic compares the caller's file system user ID directly against the raw, unmapped owner identifier stored on disk. This bypasses the intended security boundary provided by idmapped mounts, effectively ignoring the namespace mappings that define who is authorized to perform administrative actions within that specific mount context.
The operational impact of this vulnerability is twofold and presents a severe risk to system integrity and confidentiality. First, legitimate administrators or processes operating under mapped user identities may be incorrectly denied access with an EACCES error when attempting to set encryption policies on files they are authorized to manage according to the idmap configuration. This denial of service disrupts administrative workflows and can prevent critical security configurations from being applied. Conversely, and more dangerously, unrelated callers whose user IDs happen to match the unmapped owner ID may be incorrectly granted permission to modify encryption settings. This unauthorized access allows attackers or malicious processes outside the intended namespace scope to alter file encryption policies, potentially leading to data exposure if they remove existing protections or introduce weak cryptographic parameters that compromise the confidentiality of stored data.
This flaw aligns with CWE-269, which describes Improper Privilege Management, as it involves a failure to correctly enforce access control based on user identity and context. Furthermore, from an offensive security perspective, this vulnerability facilitates privilege escalation within containerized or namespace-isolated environments by allowing unprivileged users to manipulate file attributes that should be restricted to specific mapped owners. It also intersects with ATT&CK techniques related to Defense Evasion, specifically the manipulation of access controls to bypass intended restrictions on sensitive files. The misconfiguration essentially weakens the isolation guarantees provided by user namespaces and idmapped mounts, which are foundational for secure multi-tenant environments and container security models in modern Linux distributions.
To mitigate this vulnerability, system administrators must ensure that their kernels are updated with patches that correct the fscrypt_ioctl_set_policy() function to utilize file_mnt_idmap(filp) instead of nop_mnt_idmap. This change ensures that the privilege check respects the active mount's identity mapping configuration, thereby correctly validating the caller against the mapped owner rather than the raw on-disk identifier. Organizations relying on idmapped mounts for security isolation should prioritize applying this kernel update immediately to restore proper access control boundaries. Additionally, auditing logs for unexpected EACCES errors or unauthorized policy changes can help detect exploitation attempts in environments where patching might be delayed. Regular review of filesystem permissions and encryption policies is also recommended to ensure that no unintended modifications have occurred due to the previous logic flaw.