CVE-2026-53368

f2fs: fix fsck inconsistency caused by incorrect nat_entry flag usage

CVE-2026-53368 is fixed in linux on 1 platform, first by DEBIAN-CVE-2026-53368, released July 20, 2026. It is not reported as exploited. Patch Radar priority: High.

High
CVSS
7.1
Important
Exploitation
None reported
No vendor assessment
CISA KEV
Not listed
Not in the Known Exploited Vulnerabilities catalog
EPSS
0.0017
6th percentile

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.

Where it's fixed

ProductFixed inFixReleased
Linux
linux · Debian 13.5 (trixie) 6.12.115-2 DEBIAN-CVE-2026-53368 Jul 20, 2026
linux · Debian 14 7.0.7-1 DEBIAN-CVE-2026-53368 Jul 20, 2026

Patch Radar data is free to use with attribution. Terms and how to credit it.

Product names, logos and trademarks shown on Patch Radar belong to their respective owners. They are used only to identify the software each security fix applies to and to help readers find their platform. Their use does not imply any affiliation with, or endorsement by, those owners, and Patchblox is not affiliated with any of them.