CVE-2026-23267
Received Received - Intake
Race Condition in Linux Kernel F2FS Causes Checkpoint Flag Inconsistency

Publication date: 2026-03-18

Last updated on: 2026-03-18

Assigner: kernel.org

Description
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.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2026-03-18
Last Modified
2026-03-18
Generated
2026-05-07
AI Q&A
2026-03-18
EPSS Evaluated
2026-05-05
NVD
CVE-2026-23267
EUVD
EUVD-2026-12908
Affected Vendors & Products
Showing 2 associated CPEs
Vendor Product Version / Range
linux linux_kernel *
linux_kernel f2fs *
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-UNKNOWN
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

This vulnerability is a flag inconsistency issue in the Linux kernel's F2FS filesystem related to atomic commit and checkpoint writes. Specifically, during atomic file fsync operations, there is a race condition between two threads where one thread writes a checkpoint and sets a flag (IS_CHECKPOINTED) indicating completion, but the other thread does not see this flag set and attempts to write the same data again. This causes an -EINVAL error during recovery and inconsistent state in the filesystem metadata.

The problem arises because the IS_CHECKPOINTED flag is not properly set or checked due to concurrent operations, leading to redundant writes and potential data inconsistency. The fix involves ensuring that the node_write lock is properly acquired during atomic writes so that the IS_CHECKPOINTED flag correctly reflects the checkpoint write completion.


How can this vulnerability impact me? :

This vulnerability can cause errors (-EINVAL) during filesystem recovery and may lead to inconsistent filesystem metadata after reboot. In atomic write scenarios, it can cause redundant writes and potential corruption or instability in the F2FS filesystem.

Such inconsistencies could result in data loss or filesystem corruption, impacting system reliability and data integrity, especially in systems relying on atomic file operations.


How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:

I don't know


How can this vulnerability be detected on my network or system? Can you suggest some commands?

I don't know


What immediate steps should I take to mitigate this vulnerability?

I don't know


Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart