PatchSiren cyber security CVE debrief
CVE-2026-23267 Linux CVE debrief
A race condition in the F2FS (Flash-Friendly File System) atomic commit path can cause checkpoint metadata inconsistency, leading to mount failures after sudden power-off (SPO). The vulnerability stems from inadequate synchronization between atomic write commits and checkpoint operations on the `IS_CHECKPOINTED` NAT entry flag. When Thread A performs an atomic commit while Thread B executes a checkpoint, the node write semaphore (`sbi->node_write`) is not held across the critical section in `__write_node_folio`, allowing the checkpoint to set `IS_CHECKPOINTED` on a NAT entry whose folio is subsequently re-dirtied and re-written. After SPO and reboot, `f2fs_recover_inode_page` encounters a non-NULL `blk_addr` in `node_info` without the expected flag state, returning `-EINVAL` and preventing mount. The fix acquires `sbi->node_write` in `__write_node_folio` during atomic file fsync to serialize against checkpoint completion. This issue is specific to atomic writes; regular fsync is not affected because dirty folio state and `nr_pages[F2FS_DIRTY_NODES]` provide sufficient synchronization.
- Vendor
- Linux
- Product
- Unknown
- CVSS
- MEDIUM 5.5
- CISA KEV
- Not listed in stored evidence
- Original CVE published
- 2026-03-18
- Original CVE updated
- 2026-05-29
- Advisory published
- 2026-03-18
- Advisory updated
- 2026-05-29
Who should care
Organizations running Linux systems with F2FS on flash storage, particularly those using atomic write capabilities for databases or transactional workloads requiring crash consistency. Infrastructure teams managing edge devices, embedded systems, or servers with F2FS root filesystems should prioritize this patch to avoid unrecoverable mount failures after power events.
Technical summary
In F2FS, concurrent `f2fs_ioc_commit_atomic_write` (Thread A) and `f2fs_write_checkpoint` (Thread B) can interleave such that Thread A's `__write_node_folio` for the inode folio is delayed until after Thread B sets `IS_CHECKPOINTED` on the corresponding NAT entry and completes the checkpoint. Thread A then re-sets `fsync_mark` and `dentry_mark`, re-dirties the folio, and re-writes it. After SPO, recovery finds `node_info->blk_addr` non-NULL without the expected flag consistency, causing `f2fs_recover_inode_page` to return `-EINVAL`. The root cause is that `sbi->node_write` is not held in `__write_node_folio` during atomic commits, unlike regular fsync where dirty-node page counts enforce serialization. The fix ensures `sbi->node_write` is acquired through `__write_node_folio` for atomic file fsync, preventing the interleaving.
Defensive priority
medium
Recommended defensive actions
- Apply the appropriate stable kernel patch for your branch: 6.1.164+, 6.6.127+, 6.12.74+, 6.18.13+, or 6.19.3+.
- If running F2FS with atomic write workloads, prioritize kernel updates to prevent metadata corruption that can render the filesystem unmountable after power loss.
- For systems where immediate patching is not feasible, consider disabling atomic write features if operationally acceptable, or ensure robust UPS/power-failure protection to reduce SPO exposure.
- Validate filesystem integrity after any unexpected power loss using `fsck.f2fs` before mounting.
Evidence notes
Race condition confirmed through SPO testing with two-thread interleaving scenario. Affected versions span Linux kernel 4.7 through 6.19.2 across multiple stable branches. Six stable kernel patches are available. CVSS 3.1 vector AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H yields 5.5 (MEDIUM).
Official resources
-
CVE-2026-23267 CVE record
CVE.org
-
CVE-2026-23267 NVD detail
NVD
-
Source item URL
nvd_modified
-
Mitigation or vendor reference
416baaa9-dc9f-4396-8d5f-8c081fb06d67 - Patch
-
Mitigation or vendor reference
416baaa9-dc9f-4396-8d5f-8c081fb06d67 - Patch
-
Mitigation or vendor reference
416baaa9-dc9f-4396-8d5f-8c081fb06d67 - Patch
-
Mitigation or vendor reference
416baaa9-dc9f-4396-8d5f-8c081fb06d67 - Patch
-
Mitigation or vendor reference
416baaa9-dc9f-4396-8d5f-8c081fb06d67 - Patch
-
Mitigation or vendor reference
416baaa9-dc9f-4396-8d5f-8c081fb06d67 - Patch
2026-03-18