CVE-2024-47740 in Linux
Summary
by MITRE • 10/21/2024
In the Linux kernel, the following vulnerability has been resolved:
f2fs: Require FMODE_WRITE for atomic write ioctls
The F2FS ioctls for starting and committing atomic writes check for inode_owner_or_capable(), but this does not give LSMs like SELinux or Landlock an opportunity to deny the write access - if the caller's FSUID matches the inode's UID, inode_owner_or_capable() immediately returns true.
There are scenarios where LSMs want to deny a process the ability to write particular files, even files that the FSUID of the process owns; but this can currently partially be bypassed using atomic write ioctls in two ways:
- F2FS_IOC_START_ATOMIC_REPLACE + F2FS_IOC_COMMIT_ATOMIC_WRITE can truncate an inode to size 0 - F2FS_IOC_START_ATOMIC_WRITE + F2FS_IOC_ABORT_ATOMIC_WRITE can revert changes another process concurrently made to a file
Fix it by requiring FMODE_WRITE for these operations, just like for F2FS_IOC_MOVE_RANGE. Since any legitimate caller should only be using these ioctls when intending to write into the file, that seems unlikely to break anything.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 01/19/2026
The vulnerability described in CVE-2024-47740 affects the Linux kernel's F2FS (Flash-Friendly File System) implementation and represents a privilege escalation and access control bypass issue. This flaw specifically impacts the atomic write ioctl operations within the F2FS filesystem driver, creating a security gap that allows processes to circumvent mandatory access control mechanisms implemented by Linux Security Modules (LSMs) such as SELinux and Landlock. The vulnerability stems from the improper permission checking mechanism used by the F2FS ioctls for managing atomic write operations, which fails to properly enforce write access controls that are critical for maintaining system security boundaries.
The technical root cause lies in how the F2FS filesystem handles permission validation for atomic write operations through the inode_owner_or_capable() function. This function only checks if the caller's filesystem user ID (FSUID) matches the inode's user ID, effectively bypassing any LSM-based access control decisions that might otherwise deny write access to files owned by the process. The vulnerability manifests in two distinct attack vectors: first, the combination of F2FS_IOC_START_ATOMIC_REPLACE followed by F2FS_IOC_COMMIT_ATOMIC_WRITE can truncate inodes to zero size, and second, the pairing of F2FS_IOC_START_ATOMIC_WRITE with F2FS_IOC_ABORT_ATOMIC_WRITE can revert concurrent modifications made by other processes. These operations can be exploited to manipulate file contents in ways that circumvent normal file access controls, essentially allowing malicious processes to modify files they shouldn't be able to access according to LSM policies.
The operational impact of this vulnerability extends beyond simple privilege escalation to encompass broader system integrity concerns. Attackers could potentially use this vulnerability to bypass security policies configured through SELinux or Landlock, particularly in environments where fine-grained access controls are essential for protecting sensitive data. The ability to truncate files or revert concurrent changes represents a significant threat to data consistency and confidentiality, as it allows unauthorized modifications to occur without proper access control enforcement. This vulnerability affects systems running Linux kernels with F2FS filesystem support, particularly those implementing LSMs for enhanced security controls, and could be exploited in scenarios where attackers have low-privilege access but need to manipulate specific files that are normally protected by access control policies.
The fix implemented for this vulnerability requires that atomic write ioctls demand FMODE_WRITE permission, aligning the behavior with other similar operations like F2FS_IOC_MOVE_RANGE that already enforce write mode requirements. This change ensures that the kernel properly validates write access for atomic operations, preventing the bypass of LSM controls that depend on proper file mode checking. The solution addresses the underlying CWE-284 (Improper Access Control) vulnerability by enforcing proper permission semantics and aligns with ATT&CK technique T1068 (Exploitation for Privilege Escalation) by closing a pathway that could be used to escalate privileges through improper access control enforcement. The mitigation approach is conservative and unlikely to break legitimate functionality since any legitimate caller would already be attempting to write to files when using these ioctls, making the additional permission requirement both necessary and compatible with expected usage patterns. This fix strengthens the kernel's security posture by ensuring that atomic write operations properly respect the mandatory access control mechanisms that are fundamental to Linux security frameworks.