CVE-2024-47740: f2fs: Require FMODE_WRITE for atomic write ioctls
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.
Security readout for executives and security teams
Plain-English summary
A local user can bypass write restrictions enforced by security modules such as SELinux or Landlock on F2FS files they own. The flaw can erase file contents or undo another process’s changes, creating serious integrity and availability risk. It does not provide remote access or expose file contents.
Executive priority
Treat this as a high-priority local security-control bypass on F2FS systems, especially shared hosts or endpoints running untrusted code. It is less urgent for systems without F2FS or without local untrusted execution. Patch through supported kernel channels after confirming applicability; no evidence supplied supports emergency response for active exploitation.
Technical view
Affected F2FS atomic-write ioctls relied on inode_owner_or_capable(). When the caller’s filesystem UID matched the inode owner, that check could succeed without allowing an LSM to deny writing. The kernel fix requires FMODE_WRITE for these operations, closing paths that could truncate a file or revert concurrent modifications.
Likely exposure
Exposure requires Linux with an affected kernel, an F2FS filesystem, and a local low-privileged process that owns a targeted inode despite LSM write restrictions. Systems without F2FS are not exposed through this flaw. The supplied version data is ambiguous, so confirm status using the distribution or kernel vendor’s advisory and backport information.
Exploitation context
The CVSS vector describes local, low-complexity exploitation requiring low privileges and no user interaction. Impact is high for integrity and availability, with no stated confidentiality impact. The supplied sources do not report active exploitation, and the CVE is not listed as KEV in the bundle. That absence does not prove exploitation has never occurred.
Researcher notes
The two documented effects are zero-length truncation through atomic replace and rollback of another process’s concurrent changes through atomic-write abort. Exploitation depends on inode ownership bypassing the intended LSM decision. The remediation aligns these ioctls with F2FS_IOC_MOVE_RANGE by requiring FMODE_WRITE. No CWE classification or public exploit evidence is supplied.
Mitigation direction
Install a vendor kernel containing the cited FMODE_WRITE fix or an equivalent backport.
Check distribution advisories because the supplied affected-version boundaries are not sufficiently clear.
Limit untrusted local execution on systems using F2FS until remediation is confirmed.
Prioritize systems where LSM policies protect owner-controlled files from modification.
Validation and detection
Inventory F2FS mounts and record the running kernel version on each host.
Confirm the installed kernel package includes the vendor backport for CVE-2024-47740.
Verify the relevant stable-kernel fix is present in custom kernel source or build records.
Run an authorized regression test confirming LSM-denied files cannot be altered through affected atomic-write operations.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cve · low confidence lookup
CVE-2024-47740 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
We collect every scored CVSS vector available in the official CNA and ADP containers. When more than one version is present, the table keeps the source vectors side by side instead of collapsing them into the highest score.