Look up another CVE · open CVE-2026-53368 in the interactive tracker

CVE-2026-53368

f2fs: fix fsck inconsistency caused by incorrect nat_entry flag usage

7.1 EPSS 0.2% AV:L

Published 2026-07-19 (3 months ago) by the Linux kernel CNA. Subsystem fs/f2fs. Debian urgency: not yet assigned.

What to do, per Debian release

Debian's own status for CVE-2026-53368 in every release this site tracks, and what each one means in practice. Every status below is the one the Debian Security Team publishes for this CVE. source

Release	Status	Version	What this means
Debian 12bookworm	vulnerable	6.1.190-1	No fix published anywhere yet, neither in Debian nor upstream for the series bookworm tracks. Watch the Debian tracker page for this CVE. Advisories for bookworm have historically landed a median of 23 days after publication.
Debian 13trixie	vulnerable	6.12.113-1	No fix published anywhere yet, neither in Debian nor upstream for the series trixie tracks. Watch the Debian tracker page for this CVE. Advisories for trixie have historically landed a median of 11 days after publication.
Debian 14forky	fixed	7.0.7-1	Update the kernel and reboot. Fixed in 7.0.7-1. A running kernel keeps the old code until the machine restarts.
Debian unstablesid	fixed	7.0.7-1	Update the kernel and reboot. Fixed in 7.0.7-1. A running kernel keeps the old code until the machine restarts.

The vulnerability

What the bug is

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 lives

The fix touches these files. If the subsystem is one you do not use, the practical exposure is lower, though the package is still the vulnerable one.

fs/f2fs/node.c

What this is: F2FS FILE SYSTEMMAINTAINERS section matched on fs/f2fs/ · linux-f2fs-devel@lists.sourceforge.net · Maintained
Kernel module: f2fs

Check it on the machine

grep -w CONFIG_F2FS_FS /boot/config-$(uname -r)

Reads the booted kernel's own configuration, on the machine and nowhere else. =y is built in, =m is a module, and an is not set line means the code is not there.

lsmod | grep -w f2fs

Prints a line if that module is loaded right now, and nothing if it is not. One that is not loaded can still be loaded later by anything that needs it.

Show whether Debian builds this, per release

Debian builds this, but not on every flavour. At least one release below builds the code on some of its kernel flavours and not on others, so the answer depends on the architecture and flavour installed.

bookworm, trixie, forky, sidMnot built on amd64/cloud-amd64, arm64/cloud-arm64

M: a module where it is built at all; some flavours do not build it

Build switch: CONFIG_F2FS_FS

From the configuration Debian publishes for every kernel flavour it builds. It covers only the architectures Debian ships a linux-config package for, and nothing about a kernel you built yourself. Debian's own status above stays authoritative about the source package.MAINTAINERS kbuild Makefiles Debian linux-config packages

Debian tracker CVE record NVD kernel CNA record

Signals

Published: 2026-07-19 (3 months ago)source
CVSS: 7.1 high
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:Hsource recompute it
Attack vector: local (AV:L)source
EPSS: 0.17%, higher than 5.8% of all CVEssource
CISA KEV: not listedthe KEV catalogue
Debian urgency: not yet assignedsource
Subsystem: fs/f2fs

Upstream fixes

The versions the CNA records as introducing and fixing this, and the commit for each. source

Introduced	Fixed in	Commit
3.18	6.18.30	bedb710b63ae
3.18	7.0.7	b28a83ea4934
3.18	7.1	019f9dda7f66

Why the CNA scored it this way

Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source

AV:LAttack vector, local: The bug is reached via local filesystem syscalls (fsync/fdatasync on a writable file) on an F2FS mount. F2FS is primarily deployed on local flash storage (Android /data, ChromeOS, embedded), not as a network-facing attack surface.
AC:LAttack complexity, low: An attacker controls both sides of the race by concurrently fsyncing an inline inode while triggering a checkpoint (e.g., via sync(2), heavy writeback, or background checkpoint/GC threads). No conditions outside attacker influence are required beyond routine concurrent I/O.
PR:LPrivileges required, low: Exploitation requires only unprivileged write access to files on the F2FS filesystem plus the ability to issue fsync/sync syscalls. No CAP_SYS_ADMIN, mount privileges, or init-namespace root are needed.
UI:NUser interaction, none: No victim interaction is required; the attacker performs the write and fsync operations on files they can already modify.
S:UScope, unchanged: The impact is confined to F2FS on-disk metadata and recovery semantics within the same kernel/filesystem security boundary. There is no VM escape, sandbox breakout, or cross-authority boundary crossing.
C:NConfidentiality impact, none: The bug causes incorrect setting of the DENT_BIT_SHIFT recovery flag on a node block. It does not read kernel memory, leak pointers, or disclose data beyond what the attacker already wrote.
I:HIntegrity impact, high: The race writes incorrect dentry recovery metadata to disk (checkpointed inode still marked with DENT_BIT_SHIFT), producing fsck-detectable filesystem inconsistency and potentially breaking roll-forward recovery of fsynced data after sudden power-off.
A:HAvailability impact, high: Corrupted recovery metadata can cause mount-time recovery failures (as seen in the related atomic-write variant returning -EINVAL from f2fs_recover_inode_page) and fsck-detected inconsistency after power loss, degrading filesystem availability on F2FS-backed systems such as Android devices.