fix fsck inconsistency caused by incorrect nat_entry flag usage
Summary
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. A flaw was found in the Linux kernel's F2FS (Flash-Friendly File System) component.
What this means
In plain English
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.
Recommended action
The parsed official advisory does not currently specify a fixed release, mitigation, or workaround. Review the linked vendor advisory for the latest guidance before making changes.
Rewritten locally from the scraped official advisory data above; no generative API is used. The vendor advisory is authoritative.
Affected versions
No affected-version range was extracted from the source record. The vendor advisory is authoritative — check it before change work.
Official advisory · medium-confidence parse· fetched 2 hours ago·verify at source
Fixed versions
No fixed release is recorded yet. That does not prove no patch exists — confirm against the vendor advisory.
Official advisory · medium-confidence parse· fetched 2 hours ago·verify at source
Mitigation
The source record does not include mitigation steps. That is not a statement that no fix exists — read the vendor advisory below for the authoritative guidance.
Official advisory · medium-confidence parse· fetched 2 hours ago·verify at source
Discussion(0)
No comments yet. Share field notes, upgrade gotchas, or questions — verify against the vendor advisory before acting on community advice.
Sign in to join the discussion.