CVE-2026-53368: f2fs: fix fsck inconsistency caused by incorrect nat_entry flag usage

Published Jul 19, 2026
·
Updated

In the Linux kernel, the following vulnerability has been resolved:

f2fs: fix fsck inconsistency caused by incorrect natentry flag usage

f2fsneeddentrymark() reads natentry 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 - f2fsdosyncfile // inline inode - f2fswriteinode // inode folio is dirty - f2fswritecheckpoint - f2fsflushmergedwrites - f2fssyncnodepages - f2fsfsyncnodepages // no dirty node - f2fsneedinodeblockupdate // return true - f2fsfsyncnodepages // inode dirtied - f2fsneeddentrymark //return true - f2fsflushnatentries - f2fswritecheckpoint end - writenodefolio // inode with DENTBITSHIFT set SPO, "fsck --dry-run" find inode has already checkpointed but still with DENTBITSHIFT set

The state observed by f2fsneeddentrymark() can differ from the state observed in writenodefolio() after acquiring sbi->nodewrite. The root cause is that the semantics of ISCHECKPOINTED and HASFSYNCEDINODE are only guaranteed after the checkpoint write has fully completed.

This patch moves setdentrymark() into writenodefolio() and protects it with the sbi->nodewrite lock.

Affected Software

3 affected components
Linux Kernel Linux kernel
Linux Linux kernel>=3.18<6.18.30
Linux Linux kernel>=6.19<7.0.7

Remediation

Recommended actions to resolve this vulnerability, in priority order.

  1. Configuration

    Update the f2fs implementation so set_dentry_mark() is moved into __write_node_folio(), and protect the state used by f2fs_need_dentry_mark() with the sbi->node_write lock to prevent nat_entry flag state from differing without mutual exclusion.

    Linux f2fs (filesystem) set_dentry_mark placement = moved into __write_node_folio()
  2. Compensating control

    Ensure the storage/filesystem operation sequence follows the checkpoint semantics described: treat HAS_FSYNCED_INODE as only guaranteed after the checkpoint write has fully completed (i.e., after f2fs_write_checkpoint).

Event History

Jul 19, 2026
CVE Published
via MITRE·09:10 AM
Data Sourced
via MITRE·09:10 AM
DescriptionSeverity
Data Sourced
via NVD·09:17 AM
RemedyDescriptionSeverityAffected Software
Free Weekly Intel

Don't miss critical vulnerabilities

Join thousands of security professionals who receive our weekly digest of trending CVEs, zero-days, and exploited vulnerabilities.

No spam. Unsubscribe anytime.

Frequently Asked Questions

1

What is the severity of CVE-2026-53368?

CVE-2026-53368 has a high severity score of 7.1 on the CVSS scale.

2

How do I fix CVE-2026-53368?

To fix CVE-2026-53368, update your Linux Kernel to the latest version where this vulnerability has been addressed.

3

What are the potential impacts of CVE-2026-53368?

CVE-2026-53368 could lead to data corruption due to incorrect inode block marking.

4

Which systems are affected by CVE-2026-53368?

CVE-2026-53368 affects systems running vulnerable versions of the Linux Kernel utilizing f2fs.

5

Can CVE-2026-53368 be exploited remotely?

CVE-2026-53368 requires local access to exploit, as it involves interactions with file system operations.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203