CVEvulnerability

CVE-2024-47740

5.5 MEDIUM Published 2024-10-21 Modified 2026-08-04 Official page ↗
Status
Modified
Published
2024-10-21
Last modified
2026-08-04
Assigner
416baaa9-dc9f-4396-8d5f-8c081fb06d67
CVSS 3.1 (416baaa9-dc9f-4396-8d5f-8c081fb06d67)
7.1 HIGH — CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H
CVSS 3.1 ([email protected])
5.5 MEDIUM — CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

Description

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.

Affected configurations

• linux linux kernel (>= 3.18 < 4.19.323) • linux linux kernel (>= 4.20 < 5.4.285) • linux linux kernel (>= 5.5 < 5.10.227) • linux linux kernel (>= 5.11 < 5.15.168) • linux linux kernel (>= 5.16 < 6.1.113) • linux linux kernel (>= 6.2 < 6.6.54) • linux linux kernel (>= 6.7 < 6.10.13) • linux linux kernel (>= 6.11 < 6.11.2)

References