CVE-2026-23267: f2fs: fix IS_CHECKPOINTED flag inconsistency issue caused by concurrent atomic commit and checkpoint writes
In the Linux kernel, the following vulnerability has been resolved:
f2fs: fix IS_CHECKPOINTED flag inconsistency issue caused by concurrent atomic commit and checkpoint writes
During SPO tests, when mounting F2FS, an -EINVAL error was returned from
f2fs_recover_inode_page. The issue occurred under the following scenario
Thread A Thread B
f2fs_ioc_commit_atomic_write
- f2fs_do_sync_file // atomic = true
- f2fs_fsync_node_pages
: last_folio = inode folio
: schedule before folio_lock(last_folio) f2fs_write_checkpoint
- block_operations// writeback last_folio
- schedule before f2fs_flush_nat_entries
: set_fsync_mark(last_folio, 1)
: set_dentry_mark(last_folio, 1)
: folio_mark_dirty(last_folio)
- __write_node_folio(last_folio)
: f2fs_down_read(&sbi->node_write)//block
- f2fs_flush_nat_entries
: {struct nat_entry}->flag |= BIT(IS_CHECKPOINTED)
- unblock_operations
: f2fs_up_write(&sbi->node_write)
f2fs_write_checkpoint//return
: f2fs_do_write_node_page()
f2fs_ioc_commit_atomic_write//return
SPO
Thread A calls f2fs_need_dentry_mark(sbi, ino), and the last_folio has
already been written once. However, the {struct nat_entry}->flag did not
have the IS_CHECKPOINTED set, causing set_dentry_mark(last_folio, 1) and
write last_folio again after Thread B finishes f2fs_write_checkpoint.
After SPO and reboot, it was detected that {struct node_info}->blk_addr
was not NULL_ADDR because Thread B successfully write the checkpoint.
This issue only occurs in atomic write scenarios. For regular file
fsync operations, the folio must be dirty. If
block_operations->f2fs_sync_node_pages successfully submit the folio
write, this path will not be executed. Otherwise, the
f2fs_write_checkpoint will need to wait for the folio write submission
to complete, as sbi->nr_pages[F2FS_DIRTY_NODES] > 0. Therefore, the
situation where f2fs_need_dentry_mark checks that the {struct
nat_entry}->flag /wo the IS_CHECKPOINTED flag, but the folio write has
already been submitted, will not occur.
Therefore, for atomic file fsync, sbi->node_write should be acquired
through __write_node_folio to ensure that the IS_CHECKPOINTED flag
correctly indicates that the checkpoint write has been completed.
Security readout for executives and security teams
Plain-English summary
CVE-2026-23267 is a Linux kernel F2FS filesystem consistency bug. Under a narrow atomic-write and checkpoint race, recovery after sudden power-off can fail with an invalid inode-page recovery condition. Business impact is mainly reliability and data-integrity risk on systems that actually use F2FS.
Executive priority
Treat as targeted operational risk, not an internet-wide emergency. Prioritize patching where F2FS protects business-critical data, especially systems exposed to power-loss or crash-recovery scenarios. Deprioritize systems without F2FS after confirming inventory.
Technical view
The issue is an F2FS race between atomic commit fsync handling and checkpoint writes. IS_CHECKPOINTED can lag actual checkpoint completion, causing dentry marks and a second node-page write after checkpointing. The fix changes atomic file fsync behavior to acquire node_write through __write_node_folio so the checkpoint flag reflects completion consistently.
Likely exposure
Exposure appears limited to Linux systems running affected kernels with F2FS mounted and atomic write scenarios. Systems that do not use F2FS are unlikely to be exposed based on the provided description. The affected-version data is incomplete and should be validated against distro kernel advisories.
Exploitation context
The source bundle does not show KEV listing, active exploitation, public exploit activity, CVSS, or CWE mapping. The described trigger came from sudden power-off testing and a concurrency race, not a documented remote attack path.
Researcher notes
Evidence points to a filesystem consistency race, not memory corruption or privilege escalation. The record says the issue only occurs in atomic write scenarios. Severity is unknown, so conclusions about exploitability and business impact should remain conservative until vendor advisories add scoring or impact detail.
Mitigation direction
Apply Linux kernel or vendor updates containing the referenced stable F2FS fixes.
Check distribution advisories for CVE-2026-23267 backport status.
Prioritize systems using F2FS for production storage or embedded workloads.
Validate backup and recovery procedures for affected F2FS systems.
Avoid relying on unsupported kernels where no vendor fix is available.
Validation and detection
Inventory Linux kernel versions across systems using F2FS.
Confirm whether F2FS filesystems are mounted in production.
Review vendor changelogs for CVE-2026-23267 or referenced stable commits.
Assess whether workloads use F2FS atomic write paths.
Run recovery regression testing after patching in staging.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cve · low confidence lookup
CVE-2026-23267 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
0CVSS vectors
3Timeline events
0ADP providers
7Source links
Vulnerability timeline
Timeline events are normalized from CVE metadata, CNA source timelines, ADP timelines, and KEV metadata when present.
CVE reservedCVE Program
The CVE ID was reserved by the assigning CNA.
CVE publishedCVE Program
The CVE record was published.
Mar 18, 2026, 17:46 UTC (UTC+00:00)
CVE updatedCVE Program
The CVE record metadata indicates this as the latest update time.