Answer in brief
CVE-2024-47740 records a Unknown severity vulnerability in f2fs: Require FMODE_WRITE for atomic write ioctls. The current sources do not mark it as known exploited. The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
Answer in brief
CVE-2024-47740 records a Unknown severity vulnerability in f2fs: Require FMODE_WRITE for atomic write ioctls. The current sources do not mark it as known exploited. The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
A CVSS score is not reported in the current record. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| Linux/Linuxgeneric | >=88b88a66797159949cec32eaab12b4968f6fae2d <700f3a7c7fa5764c9f24bbf7c78e0b6e479fa653 || >=88b88a66797159949cec32eaab12b4968f6fae2d <4ce87674c3a6b4d3b3d45f85b584ab8618a3cece || >=88b88a66797159949cec32eaab12b4968f6fae2d <000bab8753ae29a259feb339b99ee759795a48ac || >=88b88a66797159949cec32eaab12b4968f6fae2d <88ff021e1fea2d9b40b2d5efd9013c89f7be04ac || >=88b88a66797159949cec32eaab12b4968f6fae2d <32f348ecc149e9ca70a1c424ae8fa9b6919d2713 || >=88b88a66797159949cec32eaab12b4968f6fae2d <5e0de753bfe87768ebe6744d869caa92f35e5731 || >=88b88a66797159949cec32eaab12b4968f6fae2d <f3bfac2cabf5333506b263bc0c8497c95302f32d || >=88b88a66797159949cec32eaab12b4968f6fae2d <4583290898c13c2c2e5eb8773886d153c2c5121d || >=88b88a66797159949cec32eaab12b4968f6fae2d <4f5a100f87f32cb65d4bb1ad282a08c92f6f591e | 700f3a7c7fa5764c9f24bbf7c78e0b6e479fa653, 4ce87674c3a6b4d3b3d45f85b584ab8618a3cece, 000bab8753ae29a259feb339b99ee759795a48ac, 88ff021e1fea2d9b40b2d5efd9013c89f7be04ac, 32f348ecc149e9ca70a1c424ae8fa9b6919d2713, 5e0de753bfe87768ebe6744d869caa92f35e5731, f3bfac2cabf5333506b263bc0c8497c95302f32d, 4583290898c13c2c2e5eb8773886d153c2c5121d, 4f5a100f87f32cb65d4bb1ad282a08c92f6f591e |
| Linux/Linuxgeneric | 3.18 | Not reported |
Published upstream
Oct 21, 2024
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Aug 5, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Aug 5, 2026
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.
Quoted source text, attributed separately from HOL analysis.
A CVSS score is not reported in the current record. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| Linux/Linuxgeneric | >=88b88a66797159949cec32eaab12b4968f6fae2d <700f3a7c7fa5764c9f24bbf7c78e0b6e479fa653 || >=88b88a66797159949cec32eaab12b4968f6fae2d <4ce87674c3a6b4d3b3d45f85b584ab8618a3cece || >=88b88a66797159949cec32eaab12b4968f6fae2d <000bab8753ae29a259feb339b99ee759795a48ac || >=88b88a66797159949cec32eaab12b4968f6fae2d <88ff021e1fea2d9b40b2d5efd9013c89f7be04ac || >=88b88a66797159949cec32eaab12b4968f6fae2d <32f348ecc149e9ca70a1c424ae8fa9b6919d2713 || >=88b88a66797159949cec32eaab12b4968f6fae2d <5e0de753bfe87768ebe6744d869caa92f35e5731 || >=88b88a66797159949cec32eaab12b4968f6fae2d <f3bfac2cabf5333506b263bc0c8497c95302f32d || >=88b88a66797159949cec32eaab12b4968f6fae2d <4583290898c13c2c2e5eb8773886d153c2c5121d || >=88b88a66797159949cec32eaab12b4968f6fae2d <4f5a100f87f32cb65d4bb1ad282a08c92f6f591e | 700f3a7c7fa5764c9f24bbf7c78e0b6e479fa653, 4ce87674c3a6b4d3b3d45f85b584ab8618a3cece, 000bab8753ae29a259feb339b99ee759795a48ac, 88ff021e1fea2d9b40b2d5efd9013c89f7be04ac, 32f348ecc149e9ca70a1c424ae8fa9b6919d2713, 5e0de753bfe87768ebe6744d869caa92f35e5731, f3bfac2cabf5333506b263bc0c8497c95302f32d, 4583290898c13c2c2e5eb8773886d153c2c5121d, 4f5a100f87f32cb65d4bb1ad282a08c92f6f591e |
| Linux/Linuxgeneric | 3.18 | Not reported |
Published upstream
Oct 21, 2024
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Aug 5, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Aug 5, 2026
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.
Quoted source text, attributed separately from HOL analysis.