EUVD-2026-64532
GHSA-7jrv-8xmf-x8j2
Severity by source
AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Idmapped mount prerequisite plus UID collision condition elevate complexity to AC:H; local authenticated access (PR:L) and high C/I/A impact on successful policy override confirmed by description.
Primary rating from Vendor (Linux).
CVSS VectorVendor: Linux
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Lifecycle Timeline
5DescriptionCVE.org
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.
AnalysisAI
Incorrect idmap context in Linux kernel fscrypt allows a low-privileged local user on an idmapped-mount filesystem to bypass ownership checks when setting fscrypt encryption policies via FSCRYPT_IOC_SET_POLICY, and simultaneously causes legitimate directory owners to be wrongly denied access with EACCES. The flaw affects ext4, f2fs, and other fscrypt-capable filesystems mounted with idmapped-mount configurations - a setup common in container runtimes and rootless Kubernetes node deployments from kernel 5.12 onward. …
Unlock full vulnerability intelligence
- Risk assessment & exploitation conditions
- Attack chain visualization
- Remediation with exact patch versions
- Threat intelligence from 22 sources
- Personal watchlist & email alerts
Free forever · No credit card required
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata
Vulnerability AssessmentAI
| Exploitation | Exploitation requires all of the following: (1) a local authenticated user account with shell access on the target system (CVSS PR:L confirmed); (2) the target filesystem - ext4 or f2fs with fscrypt enabled - must be mounted with an idmapped-mount configuration, a non-default setup primarily found in container runtimes operating in rootless mode (podman, runc with user namespaces) or Kubernetes nodes using idmapped-mount-capable container storage interfaces; and (3) the attacker's fsuid must coincide with an on-disk UID that, under the correct idmap translation, would not match the attacker's identity - creating a namespace UID collision that bypasses the ownership check. … Additional conditions and limiting factors are described in the full assessment. |
| Risk Assessment | The official CVSS 3.1 score of 7.8 (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) treats AC as Low, but this appears optimistic: exploitation requires both an idmapped mount to be actively configured and a specific UID collision between the attacker's fsuid and an on-disk directory owner UID in the wrong namespace - these are non-default, operationally constrained conditions not present in typical Linux server or desktop deployments. … Full risk analysis with EPSS, KEV, and SSVC signal comparison available after sign-in. |
| Exploit Scenario | A local attacker with a standard user account on a Kubernetes node or container host where ext4 or f2fs is mounted with an idmapped-mount configuration issues the FSCRYPT_IOC_SET_POLICY ioctl against a directory they do not own. Because the kernel compares the attacker's fsuid against unmapped on-disk UIDs (rather than applying the mount's idmap translation), a UID coincidence in the wrong namespace grants the attacker permission to impose an fscrypt encryption policy on the directory, potentially locking out the legitimate owner or controlling the encryption key. … |
| Remediation | Update the Linux kernel to a patched stable release: 6.6.152, 6.12.104, 6.18.45, 7.1.9, or 7.2 as applicable to the deployed stable branch, using the fix commits published at git.kernel.org (see stable-c references in CVE). … Detailed patch versions, workarounds, and compensating controls in full report. |
Recommended ActionAI
Within 24 hours, inventory systems running Linux kernels 5.12 or later with fscrypt-based encryption on idmapped-mount configurations (common in container runtimes and rootless Kubernetes deployments). …
Sign in for detailed remediation steps and compensating controls.
Threat intelligence, references, and detailed analysis are available after sign-in.
Same technique Information Disclosure
View allShare
External POC / Exploit Code
Leaving vuln.today