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.
- Products
- Kernel
- Affected versions
- Not specified
- Fixed versions
- 4.19.323, 5.10.227, 5.15.168, 5.4.285, 6.1.113, 6.10.13, 6.11.2, 6.6.54
- CVEs
- CVE-2024-47740
- Confirmed fixed CVEs
- Not specified
- Updated in this feed
- 2 Nov 2026, 17:04 UTC · Revision 1
Source evidence
f2fs: Require FMODE_WRITE for atomic write ioctls
core-osv · Original sourcePublished 21 Oct 2024, 12:14 UTC
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.
osv:CVE-2024-47740
Kernel
Fixed versions: 4.19.323, 5.4.285, 5.10.227, 5.15.168, 6.1.113, 6.6.54, 6.10.13, 6.11.2
Complete source record
{
"id": "256445b00c1080378b776448e40dc3b045dd61e70326d4a3ccf6f5a0040775ff",
"url": "https://osv.dev/vulnerability/CVE-2024-47740",
"method": "structured",
"payload": {
"kind": "advisory",
"title": "f2fs: Require FMODE_WRITE for atomic write ioctls",
"summary": "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.",
"evidence": "osv:CVE-2024-47740",
"products": [
{
"name": {
"value": "Kernel",
"evidence": "/affected/1/package/name"
},
"prerequisites": [],
"fixed_versions": [
{
"value": "4.19.323",
"evidence": "/affected/1/ranges"
},
{
"value": "5.4.285",
"evidence": "/affected/1/ranges"
},
{
"value": "5.10.227",
"evidence": "/affected/1/ranges"
},
{
"value": "5.15.168",
"evidence": "/affected/1/ranges"
},
{
"value": "6.1.113",
"evidence": "/affected/1/ranges"
},
{
"value": "6.6.54",
"evidence": "/affected/1/ranges"
},
{
"value": "6.10.13",
"evidence": "/affected/1/ranges"
},
{
"value": "6.11.2",
"evidence": "/affected/1/ranges"
}
],
"affected_versions": []
}
],
"severity": "high",
"structured": {
"id": "CVE-2024-47740",
"aliases": [
"CVE-2024-47740"
],
"metrics": [
{
"type": "CVSS_V3",
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H"
}
],
"affected": [
{
"ranges": [
{
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"type": "GIT",
"events": [
{
"introduced": "88b88a66797159949cec32eaab12b4968f6fae2d"
},
{
"fixed": "700f3a7c7fa5764c9f24bbf7c78e0b6e479fa653"
},
{
"fixed": "4ce87674c3a6b4d3b3d45f85b584ab8618a3cece"
},
{
"fixed": "000bab8753ae29a259feb339b99ee759795a48ac"
},
{
"fixed": "88ff021e1fea2d9b40b2d5efd9013c89f7be04ac"
},
{
"fixed": "32f348ecc149e9ca70a1c424ae8fa9b6919d2713"
},
{
"fixed": "5e0de753bfe87768ebe6744d869caa92f35e5731"
},
{
"fixed": "f3bfac2cabf5333506b263bc0c8497c95302f32d"
},
{
"fixed": "4583290898c13c2c2e5eb8773886d153c2c5121d"
},
{
"fixed": "4f5a100f87f32cb65d4bb1ad282a08c92f6f591e"
}
]
}
],
"database_specific": {
"source": "https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2024-47740.json"
}
},
{
"ranges": [
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "3.18.0"
},
{
"fixed": "4.19.323"
}
]
},
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "4.20.0"
},
{
"fixed": "5.4.285"
}
]
},
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "5.5.0"
},
{
"fixed": "5.10.227"
}
]
},
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "5.11.0"
},
{
"fixed": "5.15.168"
}
]
},
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "5.16.0"
},
{
"fixed": "6.1.113"
}
]
},
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "6.2.0"
},
{
"fixed": "6.6.54"
}
]
},
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "6.7.0"
},
{
"fixed": "6.10.13"
}
]
},
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "6.11.0"
},
{
"fixed": "6.11.2"
}
]
}
],
"package": {
"name": "Kernel",
"ecosystem": "Linux"
},
"database_specific": {
"source": "https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2024-47740.json"
}
}
],
"modified": "2026-10-28T02:30:21.401187040Z",
"provider": "osv",
"references": [
"https://git.kernel.org/stable/c/000bab8753ae29a259feb339b99ee759795a48ac",
"https://git.kernel.org/stable/c/32f348ecc149e9ca70a1c424ae8fa9b6919d2713",
"https://git.kernel.org/stable/c/4583290898c13c2c2e5eb8773886d153c2c5121d",
"https://git.kernel.org/stable/c/4ce87674c3a6b4d3b3d45f85b584ab8618a3cece",
"https://git.kernel.org/stable/c/4f5a100f87f32cb65d4bb1ad282a08c92f6f591e",
"https://git.kernel.org/stable/c/5e0de753bfe87768ebe6744d869caa92f35e5731",
"https://git.kernel.org/stable/c/700f3a7c7fa5764c9f24bbf7c78e0b6e479fa653",
"https://git.kernel.org/stable/c/88ff021e1fea2d9b40b2d5efd9013c89f7be04ac",
"https://git.kernel.org/stable/c/f3bfac2cabf5333506b263bc0c8497c95302f32d",
"https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html",
"https://lists.debian.org/debian-lts-announce/2025/03/msg00002.html",
"https://github.com/CVEProject/cvelistV5/tree/main/cves/2024/47xxx/CVE-2024-47740.json",
"https://nvd.nist.gov/vuln/detail/CVE-2024-47740",
"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git"
],
"provider_metadata": {
"cna_assigner": "Linux",
"osv_generated_from": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2024/47xxx/CVE-2024-47740.json"
}
},
"related_cves": [
{
"value": "CVE-2024-47740",
"evidence": "/id"
}
],
"security_relevant": true,
"severity_evidence": "/severity/0/score"
},
"source_id": "core-osv",
"document_id": 487481,
"published_at": "2024-10-21T12:14:09.171+00:00"
}