CVE-2026-46175

What it actually does

This is a local Linux kernel F2FS filesystem integrity flaw in foreground garbage collection (FGGC). During node block migration, F2FS failed to clear dentry and fsync markers, which could cause fsck.f2fs to misinterpret migrated node blocks as user fsync-written data. The result is filesystem metadata inconsistency, potentially leading to incorrect repair decisions, data integrity issues, or availability impact when systems rely on F2FS volumes. The CVSS vector indicates local access with low attack complexity and low privileges, with high integrity and availability impact and no direct confidentiality impact.

Why it matters to the business

Systems using F2FS-backed storage may experience filesystem inconsistencies, failed or unsafe filesystem checks, corrupted metadata, data loss, or service downtime if the affected code path is triggered. The issue is most relevant to Linux endpoints, appliances, embedded systems, Android-derived platforms, or servers that use F2FS for writable storage. It is not listed in CISA KEV, is not known to be used in ransomware campaigns, and has very low EPSS, so broad internet-scale exploitation is unlikely; however, local users or workloads with write access to F2FS volumes could still create operational risk.

How an attack unfolds

An attacker needs local access and the ability to perform filesystem operations on an affected F2FS volume. They create and synchronize files in a way that produces fsync-related node metadata, remove or alter files, and then trigger foreground garbage collection so F2FS migrates node blocks. Because the vulnerable kernel path does not clear the fsync and dentry marks during FGGC node migration, later fsck inspection may treat migrated metadata as if it were still associated with user-issued fsync writes. This can create or expose inconsistent filesystem state and may lead to incorrect fsck results, metadata corruption, data integrity loss, or denial of service. There is no public indication in the provided data of weaponized exploitation, named threat actors, or remote exploitation.

How to fix it

Upgrade to a Linux kernel build that includes the upstream F2FS fix for clearing fsync and dentry marks during foreground garbage-collection node block migration. Because no exact fixed package versions were provided, use the security advisory or kernel changelog from the operating system, appliance, or distribution vendor to identify the first fixed release for the deployed kernel line. Prioritize systems that mount F2FS volumes as writable storage. If immediate patching is not possible, reduce exposure by limiting local shell access, restricting untrusted users and workloads from writing to F2FS volumes, avoiding manual or scripted foreground garbage-collection operations from untrusted contexts, maintaining current backups, and scheduling careful filesystem checks during maintenance windows rather than relying on automated repair after unexpected shutdowns.

How to confirm the fix worked

Confirm exposure by identifying systems running Linux kernels that include F2FS support and have active or configured F2FS mounts. Verify the installed kernel version against vendor advisories or source commits that include the F2FS fix moving fsync/dentry mark handling into __write_node_folio and ensuring marks are cleared during FGGC. On test or staging systems only, validate the fix by reproducing the known sequence of synchronized file creation, deletion, sync, foreground garbage collection, and fsck.f2fs dry run; a fixed kernel should not report the referenced dentry/fsync marker inconsistency. In production, avoid destructive validation and instead confirm patched kernel packages, reboot status, and clean fsck.f2fs dry-run results during controlled maintenance.

Typical attack path

1. Gain local access to a Linux system using an affected kernel and an F2FS-mounted writable volume.
2. Create many files or filesystem objects and force synchronization operations to set fsync-related metadata state.
3. Delete or modify files and force additional synchronization to influence checkpoint and node state.
4. Trigger foreground F2FS garbage collection, either directly through available tooling or indirectly through storage pressure and filesystem activity.
5. Cause node block migration where fsync and dentry marks are not cleared correctly.
6. Rely on subsequent fsck.f2fs inspection or repair behavior to surface inconsistent metadata, potentially causing filesystem integrity issues, repair errors, data loss, or service disruption.

How to detect it

This issue is not associated with known remote exploitation, public weaponized malware, ransomware use, or named threat actors in the provided data, so detection should focus on local abuse or evidence of filesystem inconsistency. Review kernel logs, system logs, audit logs, shell history, and filesystem maintenance logs for unusual F2FS garbage-collection activity, repeated sync-heavy file creation/deletion patterns, manual use of f2fs_io gc_range, and fsck.f2fs warnings about checkpointed inodes, dentry marks, or fsync marks. Useful sources include journald, /var/log/kern.log, /var/log/messages, auditd execve records, process accounting, EDR command telemetry, shell histories, cron/systemd timers, and fsck output captured during boot or maintenance. Investigate unexpected fsck.f2fs dry-run or repair executions, F2FS corruption messages, sudden remounts read-only, storage-related service failures, and unexplained data loss on F2FS volumes. Because the underlying condition can also arise from legitimate testing or maintenance, correlate indicators with user identity, timing, filesystem mount points, and whether the kernel was vulnerable at the time.

• fsck.f2fs
• fsck --dry-run
• f2fs_io gc_range
• DENT_BIT_SHIFT
• inode has already checkpointed
• fsync mark
• dentry mark
• FGGC
• f2fs_sync_node_pages
• __write_node_folio
• F2FS-fs
• gc_range
• /sbin/fsck.f2fs
• /usr/sbin/fsck.f2fs
• /usr/bin/f2fs_io

What your security team should do

• Inventory Linux systems and appliances that use F2FS, including embedded, mobile-derived, edge, and storage-constrained platforms.
• Prioritize kernel updates for systems with writable F2FS volumes and local multi-user or containerized workloads.
• Check vendor advisories for the fixed kernel package or firmware release because fixed versions were not provided in the input.
• Restrict local access and write permissions to F2FS volumes until patched, especially for untrusted users, build jobs, containers, and application sandboxes.
• Review recent filesystem-health alerts, fsck.f2fs output, kernel logs, and storage incidents for signs of F2FS metadata inconsistency.
• Ensure backups are current before running filesystem repair tools on affected F2FS volumes.
• After patching, reboot into the fixed kernel and verify no systems remain on vulnerable kernel builds.