CVE-2026-53368

What it actually does

This is a local race condition in the Linux kernel f2fs filesystem. The flaw allows f2fs inode and directory-entry marking state to be observed inconsistently between fsync and checkpoint processing because nat_entry flags are read without the correct synchronization against the checkpoint path. A local user who can write to an f2fs-mounted filesystem may be able to trigger incorrect inode block marking, causing filesystem metadata inconsistency. The primary impacts are integrity loss and availability degradation, such as corrupted filesystem state, fsck errors, or service disruption caused by filesystem repair or remount behavior.

Why it matters to the business

Systems using f2fs for writable storage may experience filesystem inconsistency, data integrity problems, or operational downtime if the race is triggered. The risk is most relevant to Linux systems where untrusted or low-privileged local users, containers, apps, or workloads can write to f2fs-backed storage. There is no indication of known exploitation, KEV listing, ransomware use, or active public exploit maturity, and the EPSS score is very low, but the CVSS impact is meaningful because successful triggering can affect stored data and system availability.

How an attack unfolds

An attacker first needs local code execution or an account with permission to write files on a filesystem mounted with f2fs. They then repeatedly create, write, and fsync files while attempting to overlap those operations with f2fs checkpoint activity. By exercising the timing window between inode syncing, NAT entry flushing, and checkpoint completion, the attacker attempts to cause f2fs to persist an inode with an incorrect directory-entry marking state. If successful, the filesystem may later be observed as inconsistent by fsck or may require repair, potentially disrupting applications that rely on the affected storage. Exploitation does not provide direct remote access or data disclosure, but it can be used as a local integrity or denial-of-service primitive on affected kernels.

How to fix it

Upgrade to a Linux kernel version that includes the f2fs fix moving set_dentry_mark() into __write_node_folio() under the sbi->node_write lock. Because no exact fixed package versions were provided, use the latest kernel packages from the relevant Linux distribution or vendor advisory and confirm the backported f2fs patch is included. Where immediate patching is not possible, reduce exposure by avoiding f2fs for untrusted writable workloads, restricting local shell/container access to systems using f2fs, limiting write permissions on f2fs mounts, and monitoring for filesystem errors. For highly critical systems, consider migrating sensitive writable storage to a filesystem not affected by this specific f2fs race until patched.

How to confirm the fix worked

Confirm the running kernel is updated to a vendor release containing the f2fs synchronization fix for this issue. Validate that affected systems actually use f2fs by checking mounted filesystems with commands such as findmnt -t f2fs or /proc/mounts. After patching and rebooting into the fixed kernel, run vendor-supported filesystem health checks during a maintenance window, such as fsck.f2fs in dry-run mode against unmounted or safely snapshotted volumes. Review kernel logs after normal workload or controlled fsync/checkpoint stress testing for absence of new f2fs metadata inconsistency messages. Ensure the active kernel version, not just installed packages, reflects the patched release.

Typical attack path

1. Gain local access to a Linux system or workload that can write to an f2fs-mounted filesystem.
2. Identify writable paths backed by f2fs, such as application data directories, removable storage, mobile/embedded storage, or container volumes.
3. Run a tight loop that creates files, writes data, and calls fsync to force inode synchronization.
4. Attempt to overlap these operations with f2fs checkpoint activity and NAT entry flushing.
5. Trigger inconsistent inode marking due to the race between fsync and checkpoint handling.
6. Cause filesystem metadata inconsistency, fsck findings, possible repair requirements, or storage/service disruption.

How to detect it

There is no reliable single indicator proving exploitation because successful triggering resembles filesystem corruption or a kernel race. Investigate systems using f2fs that show unexpected fsck failures, metadata inconsistency, remounts, I/O errors, or application outages involving f2fs-backed paths. Collect and review kernel logs from dmesg, journald, /var/log/kern.log, /var/log/messages, and distribution-specific system logs for f2fs errors around the time of impact. Review auditd, EDR, shell history, container logs, and process accounting for users or workloads repeatedly creating files and invoking fsync-heavy test tools on f2fs mounts. Look for unusual execution of filesystem stress tools, custom loops, or programs that rapidly create, write, fsync, and delete files. If possible, preserve affected filesystem images before repair for forensic comparison, then run fsck.f2fs in a controlled manner to identify inode or checkpoint-related inconsistencies.

• f2fs
• fsck.f2fs
• fsck --dry-run
• DENT_BIT_SHIFT
• IS_CHECKPOINTED
• HAS_FSYNCED_INODE
• f2fs_write_checkpoint
• f2fs_flush_nat_entries
• f2fs_sync_node_pages
• f2fs_fsync_node_pages
• f2fs_need_dentry_mark
• __write_node_folio
• checkpoint
• NAT
• nat_entry
• inode has already checkpointed

What your security team should do

• Prioritize patching Linux systems that mount f2fs writable filesystems and allow local users, containers, mobile workloads, embedded apps, or other untrusted code to write to those filesystems.
• Inventory f2fs usage across servers, endpoints, appliances, containers, and embedded Linux images using mount data, configuration management, and kernel package inventory.
• Apply the latest vendor kernel updates and reboot systems so the fixed kernel is actually running.
• If patching is delayed, restrict untrusted write access to f2fs mounts and consider moving high-value writable data off f2fs-backed storage.
• Monitor kernel, system, and fsck logs for f2fs metadata inconsistency, checkpoint, inode, NAT, and repair messages.
• Treat unexplained f2fs corruption on multi-user systems as potentially security-relevant until kernel patch status and user activity are reviewed.
• Because this issue is not KEV-listed, has no known ransomware association, and has very low EPSS, prioritize based on actual f2fs exposure and local-user threat model rather than internet exposure.