CVE-2026-53368 in Linux
Summary
by MITRE • 07/19/2026
In the Linux kernel, the following vulnerability has been resolved:
f2fs: fix fsck inconsistency caused by incorrect nat_entry flag usage
f2fs_need_dentry_mark() reads nat_entry flags without mutual exclusion with the checkpoint path, which can result in an incorrect inode block marking state. The scenario is as follows:
create & write & fsync 'file A' write checkpoint - f2fs_do_sync_file // inline inode - f2fs_write_inode // inode folio is dirty - f2fs_write_checkpoint - f2fs_flush_merged_writes - f2fs_sync_node_pages - f2fs_fsync_node_pages // no dirty node - f2fs_need_inode_block_update // return true - f2fs_fsync_node_pages // inode dirtied - f2fs_need_dentry_mark //return true - f2fs_flush_nat_entries - f2fs_write_checkpoint end - __write_node_folio // inode with DENT_BIT_SHIFT set SPO, "fsck --dry-run" find inode has already checkpointed but still with DENT_BIT_SHIFT set
The state observed by f2fs_need_dentry_mark() can differ from the state observed in __write_node_folio() after acquiring sbi->node_write. The root cause is that the semantics of IS_CHECKPOINTED and HAS_FSYNCED_INODE are only guaranteed after the checkpoint write has fully completed.
This patch moves set_dentry_mark() into __write_node_folio() and protects it with the sbi->node_write lock.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 07/19/2026
The vulnerability in the Linux kernel's f2fs file system implementation stems from an inconsistency in how nat_entry flags are managed during the checkpointing process, specifically affecting the fsck utility's ability to accurately verify file system integrity. This issue manifests when the f2fs_need_dentry_mark() function reads nat_entry flags without proper mutual exclusion mechanisms relative to the checkpoint path execution flow. The flaw creates a race condition where the state of inode block marking becomes inconsistent between different phases of the checkpoint operation, leading to incorrect assumptions about file system metadata states.
The problematic scenario occurs during a sequence of operations involving file creation, writing, and synchronization where the file system attempts to maintain consistency through multiple checkpoint cycles. When processing 'file A' through the standard write path including f2fs_do_sync_file, f2fs_write_inode, and f2fs_write_checkpoint functions, the system creates a complex interplay between inline inode handling and node page synchronization that exposes the vulnerability. The sequence demonstrates how an inode folio can become dirty during one phase of processing while simultaneously being processed for checkpointing in another phase, creating temporal inconsistencies in flag states.
The operational impact of this vulnerability extends beyond simple data corruption concerns to affect system integrity verification mechanisms. When fsck --dry-run encounters an inode that has already been checkpointed but still retains the DENT_BIT_SHIFT flag set, it indicates a fundamental mismatch between what the file system believes is the current state versus what was actually written to persistent storage. This inconsistency can lead to false positives in file system checking operations and potentially cause fsck to make incorrect decisions about file system repair actions, which aligns with CWE-129 weakness classification related to improper handling of inconsistent data states.
The root cause analysis reveals that the semantics of IS_CHECKPOINTED and HAS_FSYNCED_INODE flags are only guaranteed to be accurate after a complete checkpoint write operation has finished executing. During intermediate phases of checkpoint processing, these flag states can become inconsistent due to concurrent access patterns and missing synchronization mechanisms. This temporal inconsistency creates a window where f2fs_need_dentry_mark() observes one state while __write_node_folio() operates on a different state, resulting in the incorrect marking of inode blocks that subsequently confuses fsck operations.
The proposed patch addresses this vulnerability by repositioning the set_dentry_mark() function directly within __write_node_folio() and protecting it through the sbi->node_write lock mechanism. This change ensures that dentry mark operations occur atomically with node folio writing, eliminating the race condition that previously allowed inconsistent flag states to persist. The solution follows established concurrency control patterns and aligns with ATT&CK technique T1486 for data manipulation by ensuring proper synchronization between different system components during critical file system operations. This mitigation approach directly addresses the lack of mutual exclusion in the original implementation while maintaining the functional requirements of the checkpointing process, thereby restoring consistency to the file system's metadata management and ensuring that fsck utilities can accurately verify file system integrity without false positives or misleading state information.