CVE detail
CVE-2026-53017
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.
Buzz score
Why this CVE is surfacing
This all-time snapshot uses the same composite formula as Trending across a 30-year evidence window, rather than a current rolling window.
Buzz score components · mention 13.9 · diversity 10.0 · KEV 0.0 · OTX 0.0 · PoC 0.0
Why it matters now
Mention timeline
- Total mentions
- 0
- within the 30d window
- Peak daily
- 0
- highest bucket
Evidence
Source links by recency
3 source links · newest first
Information published.
vendormsrc.microsoft.comJun 28, 2026, 9:04 AMNo excerpt available.
Vendor Advisorygit.kernel.orgJun 24, 2026, 5:17 PMNo excerpt available.
Vendor Advisorygit.kernel.orgJun 24, 2026, 5:17 PM
Exploit code
Public exploit repository references
Public PoC repositories are third-party, potentially unsafe artifacts. Treat their code as untrusted and use it only on authorized systems in an isolated, least-privilege environment. cvebuzz does not execute the code or verify that an exploit works.
0 repository references · best confidence N/A · max 0 stars
Related records
Similar CVEs
6 related CVEs with shared weakness or product evidence
- CVE-2026-16422CVSS 7.5 · High
Insufficient validation of untrusted input in Certificate in Google Chrome on Linux prior to 150.0.7871.182 allowed an attacker in a privileged network position to perform domain…
- CVE-2026-15904CVSS 8.8 · High
Use after free in Ozone in Google Chrome on Linux prior to 150.0.7871.128 allowed a remote attacker who convinced a user to engage in specific UI gestures to potentially exploit h…
- CVE-2026-63807CVSS 8.8 · High
In the Linux kernel, the following vulnerability has been resolved: KVM: x86/mmu: Ensure hugepage is in by slot before checking max mapping level When recovering hugepages in th…
- CVE-2026-63806CVSS 7.1 · High
In the Linux kernel, the following vulnerability has been resolved: KVM: Replace guest-triggerable BUG_ON() in ioeventfd datamatch with get_unaligned() Drop a BUG_ON() that has…
- CVE-2026-63805CVSS 7.8 · High
In the Linux kernel, the following vulnerability has been resolved: crypto: nx - fix nx_crypto_ctx_exit argument nx_crypto_ctx_shash_exit calls nx_crypto_ctx_exit with crypto_sh…
4 mentions - CVE-2026-63804CVSS 7.8 · High
In the Linux kernel, the following vulnerability has been resolved: gfs2: fix use-after-free in gfs2_qd_dealloc gfs2_qd_dealloc(), called as an RCU callback from gfs2_qd_dispose…