CVE-2026-46194

What it actually does

This is a local Linux kernel race condition in the F2FS filesystem extent-cache handling. During inode drop and extent-node destruction, concurrent writeback can insert new extent nodes into the same extent tree because the FI_NO_EXTENT guard is not set early enough and is not consistently checked for all extent types. If the race is won, an internal kernel consistency check, f2fs_bug_on(), can fire in __destroy_extent_node(), causing a kernel BUG, panic, or system crash. The practical impact is availability loss; the description does not indicate confidentiality or integrity impact.

Why it matters to the business

Systems using F2FS can be crashed by a local user or process able to exercise the affected filesystem behavior, causing service interruption, workload failure, and possible data-processing disruption. The issue is not listed in CISA KEV, has very low EPSS, and requires local access with a high-complexity race, so broad internet-scale exploitation is unlikely; however, shared Linux hosts, Android-derived systems, embedded appliances, and environments where untrusted users or containers can interact with F2FS-backed storage should treat it as a meaningful denial-of-service risk.

How an attack unfolds

An attacker first needs local code execution or an account on a system using an affected Linux kernel with F2FS mounted. They then perform filesystem operations that cause inode references to be dropped while writeback activity is occurring, such as repeatedly creating, modifying, syncing, and deleting files on F2FS-backed storage. The goal is to align f2fs_drop_inode() and f2fs_destroy_extent_node() with concurrent kworker writeback that enters f2fs_outplace_write_data() and updates the extent cache. Because FI_NO_EXTENT is not set early enough and not checked for all relevant extent-tree updates, the writeback path can add a new extent node after the destroy path believes it has removed them. When __destroy_extent_node() later validates the node count, f2fs_bug_on() can trigger and crash the kernel. Reliable exploitation is expected to be difficult because it depends on timing, kernel configuration, F2FS usage, and writeback behavior, and there is no indication of public exploit maturity in the provided data.

How to fix it

Upgrade to a Linux kernel build that includes the upstream F2FS fix for the node_cnt race between extent-node destruction and writeback. Because no exact fixed versions were provided, use the fixed kernel packages supplied by the relevant Linux distribution, appliance vendor, Android/embedded vendor, or kernel maintainer, and confirm the patch sets FI_NO_EXTENT under the extent-tree lock in __destroy_extent_node() and checks FI_NO_EXTENT for both EX_READ and EX_BLOCK_AGE updates. Where immediate patching is not possible, reduce exposure by avoiding F2FS for untrusted writable workloads, limiting local shell or container access to systems with F2FS mounts, restricting write access to F2FS-backed paths, and planning maintenance windows for kernel updates. Reboot into the patched kernel after installation; merely installing kernel packages is insufficient if the running kernel is still vulnerable.

How to confirm the fix worked

Confirm whether F2FS is in use by checking mounted filesystems and kernel support, for example with findmnt -t f2fs, mount | grep f2fs, lsmod | grep f2fs, and kernel configuration/package metadata. Confirm remediation by verifying the running kernel version after reboot with uname -a and comparing it to the distribution or vendor advisory that contains the F2FS fix. If building kernels internally, verify the source tree contains the relevant F2FS changes around __destroy_extent_node(), __update_extent_tree_range(), FI_NO_EXTENT handling, and EX_BLOCK_AGE checks. Validate operationally by confirming previously affected F2FS workloads no longer produce kernel BUG or panic messages during heavy writeback, delete, sync, and inode churn testing in a non-production environment.

Typical attack path

1. Gain local execution on a Linux system that runs an affected kernel and has an F2FS filesystem mounted or otherwise reachable.
2. Identify a writable F2FS-backed path or workload where file creation, modification, deletion, and sync/writeback activity can be induced.
3. Generate repeated filesystem churn to create and update F2FS extent-cache state.
4. Trigger inode dropping while kernel writeback workers are concurrently flushing data for the same filesystem activity.
5. Race extent-node destruction against extent-cache insertion by the writeback path.
6. Cause f2fs_bug_on() in __destroy_extent_node() to fire, resulting in a kernel BUG, panic, hang, or reboot.

How to detect it

To assess prior exploitation or triggering, review kernel logs and crash artifacts rather than network telemetry, because this is a local kernel race. Useful sources include journalctl -k, /var/log/kern.log, /var/log/messages, dmesg output, persistent pstore logs, kdump/vmcore data, systemd-coredump metadata, hypervisor reset records, and EDR telemetry for local processes performing heavy file churn before a crash. Look for kernel BUG, Oops, panic, watchdog, or unexpected reboot events that mention F2FS functions such as f2fs_bug_on, __destroy_extent_node, f2fs_destroy_extent_node, __update_extent_tree_range, f2fs_update_read_extent_cache, f2fs_outplace_write_data, or __writeback_single_inode. Correlate these events with F2FS-mounted filesystems and preceding local activity involving rapid create/write/fsync/delete loops, unusual storage stress tools, build jobs, container workloads, or unknown binaries writing heavily to F2FS-backed paths. Absence of these artifacts does not prove non-exploitation because kernel panics can truncate logs unless persistent kernel logging or crash dumps are enabled.

• f2fs_bug_on
• __destroy_extent_node
• f2fs_destroy_extent_node
• __update_extent_tree_range
• f2fs_update_read_extent_cache
• f2fs_outplace_write_data
• __writeback_single_inode
• kernel BUG at fs/f2fs
• BUG: kernel NULL pointer dereference in f2fs
• Oops: 0000 [#
• Kernel panic - not syncing
• F2FS-fs
• FI_NO_EXTENT
• EX_BLOCK_AGE
• EX_READ
• /sys/fs/pstore
• /var/crash
• /proc/vmcore

What your security team should do

• Inventory Linux systems that use F2FS, prioritizing endpoints, mobile/embedded Linux, appliances, shared compute hosts, and container platforms with local untrusted workloads.
• Patch affected systems with vendor-provided kernels that include the F2FS race-condition fix, then reboot and verify the running kernel version.
• Prioritize remediation where untrusted users, sandbox escapes, CI jobs, containers, or third-party applications can write to F2FS-backed storage.
• If patching is delayed, restrict local access and write permissions to F2FS mounts, and consider moving high-risk writable workloads to a non-affected filesystem until updates are applied.
• Enable or retain kernel crash logging, persistent journald kernel logs, kdump, and panic/reboot telemetry so availability-impacting exploitation attempts can be investigated.
• Monitor for kernel BUG, panic, oops, or reboot events referencing F2FS extent-cache functions, especially on systems with recent local filesystem churn.
• Track distribution, Android, embedded, and appliance vendor advisories because fixed version numbers may differ from upstream kernel versions and may be backported.