CVE-2026-74595: fscrypt: use the mount idmap for the owner check in fscrypt_ioctl_set_policy()
In the Linux kernel, the following vulnerability has been resolved:
fscrypt: use the mount idmap for the owner check in fscryptioctlsetpolicy()
fscryptioctlsetpolicy() calls inodeownerorcapable() with &nopmntidmap 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 filemntidmap(filp) instead.
Affected Software
Event History
Frequently Asked Questions
Which systems are exposed to the incorrect permission check?
The issue affects fscrypt policy-setting operations on filesystems that support idmapped mounts, such as ext4 and f2fs, when the ioctl is issued through an idmapped mount. Systems not using an idmapped mount are not described as affected by this owner-mapping mismatch.
What access does an attacker need to exploit this?
An attacker needs to be able to issue the fscrypt policy-setting ioctl on a file through an idmapped mount. The flawed check can then compare their fsuid with the unmapped on-disk owner and incorrectly authorize an unrelated caller.
What is the practical impact of the bug?
An unrelated caller can be wrongly allowed to set an encryption policy, while the actual mapped owner can be wrongly denied with -EACCES. The problem is limited to the ownership check used by fscrypt_ioctl_set_policy().