LiveActive security incident?Get immediate response
CVE Record

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.

UnknownCVSS not scoredNot KEV-listedUpdated
Glexia's TakeAutomated analysisunknown

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.
Prepared
Confidence
medium
Sources
8

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.

Open ATT&CK lookup
Vulnerability profileCVE Program record
Severity
Unknown
CVSS
Not scored
Known Exploited
No
Published
Official CVE source material

CNA and ADP enrichment extracted from CVE v5

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.

  1. CVE reservedCVE Program

    The CVE ID was reserved by the assigning CNA.

  2. CVE publishedCVE Program

    The CVE record was published.

  3. CVE updatedCVE Program

    The CVE record metadata indicates this as the latest update time.

Affected products

Products and packages named in the record

VendorProductVersion / packageStatus
LinuxLinux608514deba38c8611ad330d6a3c8e2b9a1f68e4b, 608514deba38c8611ad330d6a3c8e2b9a1f68e4b, 608514deba38c8611ad330d6a3c8e2b9a1f68e4b, 608514deba38c8611ad330d6a3c8e2b9a1f68e4b, 608514deba38c8611ad330d6a3c8e2b9a1f68e4b, 608514deba38c8611ad330d6a3c8e2b9a1f68e4bunaffected
LinuxLinux4.7, 0, 6.1.164, 6.6.127, 6.12.74, 6.18.13, 6.19.3, 7.0affected
Weakness

CWE details

No CWE listed

CWE links open Glexia weakness intelligence pages with official CWE context, developer remediation guidance, and related CVE mappings.