CVE-2026-53017

Published: June 26, 2026Last modified: June 26, 2026

Description

In the Linux kernel, the following vulnerability has been resolved: f2fs: fix data loss caused by incorrect use of nat_entry flag Data loss can occur when fsync is performed on a newly created file (before any checkpoint has been written) concurrently with a checkpoint operation. 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_flush_nat_entries - f2fs_fsync_node_pages // no dirty node - f2fs_need_inode_block_update // return false SPO and lost 'file A' f2fs_flush_nat_entries() sets the IS_CHECKPOINTED and HAS_LAST_FSYNC flags for the nat_entry, but this does not mean that the checkpoint has actually completed successfully. However, f2fs_need_inode_block_update() checks these flags and incorrectly assumes that the checkpoint has finished. The root cause is that the semantics of IS_CHECKPOINTED and HAS_LAST_FSYNC are only guaranteed after the checkpoint write fully completes. This patch modifies f2fs_need_inode_block_update() to acquire the sbi->node_write lock before reading the nat_entry flags, ensuring that once IS_CHECKPOINTED and HAS_LAST_FSYNC are observed to be set, the checkpoint operation has already completed.

Severity score breakdown

ParameterValue
Base score5.5
Attack VectorLOCAL
Attack complexityLOW
Privileges requiredLOW
User interactionNONE
ScopeUNCHANGED
ConfidentialityNONE
Integrity impactNONE
Availability impactHIGH
VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

Status

ProductReleasePackageStatus
Alpaquita Linux23 LTSlinux-ltsVulnerable (6.1.175-r0)
25 LTSlinux-ltsVulnerable (6.12.92-r0)
Streamlinux-ltsVulnerable (6.18.35-r1)

References

ON THIS PAGE