CVE-2024-47740

What it actually does

The F2FS atomic write ioctls (START_ATOMIC_REPLACE, COMMIT_ATOMIC_WRITE, START_ATOMIC_WRITE, ABORT_ATOMIC_WRITE) rely solely on inode_owner_or_capable() for authorization, bypassing LSM hooks such as SELinux or Landlock that would otherwise enforce FMODE_WRITE checks, enabling unauthorized truncation to zero length or reversion of concurrent file modifications.

Why it matters to the business

Organizations running affected Linux kernels on systems using F2FS may experience unauthorized file modifications that evade mandatory access controls, increasing risk of data tampering or integrity violations especially in environments with strict LSM policies; low exploitability reduces immediate urgency but kernel updates remain necessary for compliance.

How an attack unfolds

An attacker with a process whose FSUID matches the target inode UID but lacking LSM-granted write permission invokes the atomic write ioctls to either truncate the file via START_ATOMIC_REPLACE plus COMMIT_ATOMIC_WRITE or abort and discard concurrent writes via START_ATOMIC_WRITE plus ABORT_ATOMIC_WRITE, achieving effects normally denied by LSM policy.

How to fix it

Upgrade to Linux kernel commit 700f3a7c7fa5764c9f24bbf7c78e0b6e479fa653 or later; for Rocky Linux 8 apply libecap package version 1.0.1-2.module+el8.4.0+404+316a0dc5 or newer; ensure F2FS userspace tools and mount options do not grant unnecessary capabilities.

How to confirm the fix worked

Confirm kernel source contains the FMODE_WRITE requirement in the atomic write ioctl handlers; test that LSM-denied processes receive EACCES or equivalent when attempting the ioctls on owned files; review audit logs for prior ioctl invocations on F2FS inodes.

Typical attack path

1. Identify F2FS filesystem and target file owned by matching UID but protected by LSM write restrictions
2. Obtain execution context with matching FSUID but no FMODE_WRITE via LSM
3. Call F2FS_IOC_START_ATOMIC_REPLACE or F2FS_IOC_START_ATOMIC_WRITE
4. Perform truncation or allow concurrent changes then invoke COMMIT or ABORT to finalize unauthorized state change
5. Verify file state reflects the bypassed modification

How to detect it

Review kernel audit logs and SELinux denials for unexpected F2FS atomic write ioctl calls; examine process execution histories and file modification timestamps that coincide with ioctl activity on files where LSM policy should have blocked writes.

What your security team should do

• Prioritize kernel upgrades on all F2FS deployments within standard patch windows
• Audit LSM policies to ensure write restrictions remain effective post-update
• Monitor for F2FS atomic write ioctl usage in security-relevant workloads
• Include the fixed commit in automated kernel build and validation pipelines