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.
Published: 2026-03-18
Score: n/a
EPSS: < 1% Very Low
KEV: No
Impact: Potential filesystem data corruption due to inconsistent checkpoint flag after atomic commit
Action: Immediate Patch
AI Analysis

Impact

The vulnerability stems from an inconsistency in the is_checkpointed flag during concurrent atomic commit and checkpoint writes in the Linux kernel’s f2fs file system. The flag can be left unset although the checkpoint write has completed, which may cause the filesystem to write the same data twice or leave state but not properly mark a node as checkpointed. This state mismatch can impair recovery procedures, leading to data loss or corruption when the system reboots or attempts to recover the filesystem.

Affected Systems

The flaw exists in the f2fs implementation of the Linux kernel. Any system that uses the f2fs filesystem and is running a kernel version built from source before the patch is a potential target. All Linux kernel releases that include the f2fs driver before the fix are therefore affected.

Risk and Exploitability

The bug resides inside the kernel, so an attacker must generate conditions that trigger an atomic fsync while a checkpoint write is underway. The EPSS score is below 1 % and the vulnerability is not listed in the CISA KEV catalog, indicating a low to moderate exploitation likelihood. The impact is primarily local or privileged; there is no evidence of a remote code execution vector, but data integrity and system stability could be compromised.

Generated by OpenCVE AI on March 26, 2026 at 02:58 UTC.

Remediation

No vendor fix or workaround currently provided.

OpenCVE Recommended Actions

  • Apply a kernel update that contains the f2fs IS_CHECKPOINTED flag patch as released by the Linux kernel maintainers
  • Verify that the running kernel includes the patch commit identified in the referenced git changesets

Generated by OpenCVE AI on March 26, 2026 at 02:58 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

Wed, 25 Mar 2026 22:00:00 +0000

Type Values Removed Values Added
Weaknesses CWE-362
CWE-744

Wed, 25 Mar 2026 14:15:00 +0000

Type Values Removed Values Added
Weaknesses CWE-362
CWE-744

Wed, 25 Mar 2026 12:00:00 +0000

Type Values Removed Values Added
Weaknesses CWE-362
CWE-469

Tue, 24 Mar 2026 13:30:00 +0000

Type Values Removed Values Added
Weaknesses CWE-362
CWE-469

Thu, 19 Mar 2026 00:15:00 +0000


Wed, 18 Mar 2026 18:00:00 +0000

Type Values Removed Values Added
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.
Title f2fs: fix IS_CHECKPOINTED flag inconsistency issue caused by concurrent atomic commit and checkpoint writes
First Time appeared Linux
Linux linux Kernel
CPEs cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Vendors & Products Linux
Linux linux Kernel
References

Subscriptions

Linux Linux Kernel
cve-icon MITRE

Status: PUBLISHED

Assigner: Linux

Published:

Updated: 2026-04-13T06:03:15.459Z

Reserved: 2026-01-13T15:37:45.991Z

Link: CVE-2026-23267

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Awaiting Analysis

Published: 2026-03-18T18:16:25.573

Modified: 2026-03-19T13:25:00.570

Link: CVE-2026-23267

cve-icon Redhat

Severity :

Publid Date: 2026-03-18T00:00:00Z

Links: CVE-2026-23267 - Bugzilla

cve-icon OpenCVE Enrichment

Updated: 2026-03-26T12:20:49Z

Weaknesses

No weakness.