CVE-2026-74595: Linux Kernel Privilege Escalation Vulnerability

CVE-2026-74595 Overview

CVE-2026-74595 is a Linux kernel vulnerability in the fscrypt subsystem. The function fscrypt_ioctl_set_policy() performs the caller's owner check using inode_owner_or_capable() with &nop_mnt_idmap instead of the idmap of the mount on which the ioctl was issued. On filesystems that support idmapped mounts such as ext4 and f2fs, this compares the caller's fsuid against the unmapped on-disk owner. The mismatch can wrongly deny the legitimate owner with -EACCES or wrongly allow an unrelated caller to set an encryption policy. The fix replaces the placeholder idmap with file_mnt_idmap(filp).

Critical Impact
A local user on a system using idmapped mounts can set filesystem encryption policies on inodes they do not own, breaking access control assumptions for encrypted directories.

Affected Products

Linux kernel fscrypt subsystem
Filesystems using fscrypt with idmapped mounts (e.g., ext4, f2fs)
Distributions shipping affected upstream kernels prior to the referenced stable commits

Discovery Timeline

2026-08-22 - CVE-2026-74595 published to NVD
2026-08-25 - Last updated in NVD database

Technical Details for CVE-2026-74595

Vulnerability Analysis

The fscrypt_ioctl_set_policy() ioctl handler gates the ability to install an encryption policy on an inode. It calls inode_owner_or_capable() to confirm the caller owns the inode or holds CAP_FOWNER. The handler passes &nop_mnt_idmap, a no-op identity mapping, rather than the idmap associated with the mount that issued the ioctl.

On idmapped mounts, the kernel maps on-disk UIDs and GIDs to different values as seen by the caller. Skipping the mount's idmap causes the check to compare the caller's fsuid against the raw on-disk owner. The result is an incorrect authorization decision in either direction: the mapped owner is treated as a non-owner, and an unrelated user whose fsuid happens to match the on-disk UID is treated as owner.

An attacker with local access to an idmapped mount can abuse the flawed check to apply an encryption policy to directories they do not legitimately own. This changes how subsequent files under that directory are stored on disk and can be used to disrupt access or influence data confidentiality boundaries. Legitimate users may also be locked out of setting policies on their own data.

Root Cause

The root cause is an incorrect argument passed to inode_owner_or_capable(). Using &nop_mnt_idmap ignores the mount's idmap entirely. The correct value is the mount idmap obtained from the open file, file_mnt_idmap(filp), which reflects the caller's view of ownership.

Attack Vector

Exploitation requires local access, low privileges, and no user interaction. The attacker must have an open file descriptor on an idmapped mount of a filesystem that supports fscrypt, then issue the FS_IOC_SET_ENCRYPTION_POLICY ioctl against a target inode whose on-disk UID aligns with the attacker's fsuid under the flawed check. No synthetic proof-of-concept is published; see the upstream fix in Kernel Git Commit 0baeb73 for the corrected authorization path.

Detection Methods for CVE-2026-74595

Indicators of Compromise

Unexpected FS_IOC_SET_ENCRYPTION_POLICY ioctl calls issued by non-root users against directories they do not own on-disk.
New encryption policies appearing on directories where none existed and where the on-disk owner does not match the process that set the policy.
Application errors reporting -EACCES from legitimate owners attempting to set encryption policies on idmapped mounts.

Detection Strategies

Audit kernel version banners across Linux fleet inventory and flag hosts running kernels that predate the stable commits referenced in the CVE.
Enable auditd rules on the ioctl syscall filtered by the fscrypt policy ioctl numbers to record which UIDs invoke policy operations.
Correlate mount table state (/proc/self/mountinfo) with kernel version to identify hosts that both expose idmapped mounts and lack the fix.

Monitoring Recommendations

Ship kernel audit logs and mountinfo telemetry to a centralized analytics tier for longitudinal review of ioctl activity.
Alert on fscrypt policy changes performed by unprivileged accounts on shared or container-hosting systems.
Track container runtime configurations that create idmapped mounts and prioritize patching of underlying hosts.

How to Mitigate CVE-2026-74595

Immediate Actions Required

Apply the stable kernel updates that contain the fix referenced by upstream commits including Kernel Git Commit 0baeb73 and Kernel Git Commit 174633a.
Inventory hosts and container platforms that use idmapped mounts on ext4, f2fs, or other fscrypt-enabled filesystems, and schedule patching first.
Restrict local access on multi-tenant systems until updated kernels are deployed.

Patch Information

The fix replaces &nop_mnt_idmap with file_mnt_idmap(filp) in fscrypt_ioctl_set_policy(). It has been backported through multiple stable trees. Consult vendor advisories from your Linux distribution and rebase to a kernel that includes one of the referenced upstream commits: 0baeb73, 174633a, 33b7e81, 653e888, 6a67c46, 98516ba, and cf6c993.

Workarounds

Avoid configuring idmapped mounts on fscrypt-enabled filesystems until patched kernels are installed.
Limit which local users can hold open file descriptors on idmapped mounts, for example by tightening container runtime privileges.
Where feasible, disable fscrypt policy management for unprivileged users by restricting the parent directories that host encrypted subtrees.

bash

# Verify running kernel version against distribution advisories
uname -r

# Enumerate idmapped mounts to prioritize hosts for patching
awk '$0 ~ /idmapped/ {print}' /proc/self/mountinfo