CVE-2026-31715

What it actually does

This is a Linux kernel flaw in the F2FS filesystem writeback/unmount path. A race between F2FS checkpoint write completion and filesystem teardown can cause the kernel to access F2FS superblock state after it has been cleared, specifically around node_inode handling in f2fs_write_end_io()/f2fs_in_warm_node_list(). The reported failure mode is a NULL pointer dereference and kernel panic, but because the issue is in kernel memory lifetime handling and is classified as use-after-free, successful exploitation may have broader local impact, including denial of service and potentially local privilege escalation depending on kernel build, hardening, and attacker control of timing and memory state.

Why it matters to the business

Systems using the Linux kernel with mounted F2FS filesystems may be vulnerable to local attacks that crash the host and interrupt workloads. The risk is highest on endpoints, appliances, Android/Linux-derived devices, embedded systems, and servers that use F2FS for flash storage or allow users/containers to mount F2FS filesystems. The vulnerability is not listed in CISA KEV, is not known to be used in ransomware campaigns, has low EPSS activity, and has no known public exploit maturity in the provided data, so urgency is lower than for actively exploited remote flaws; however, the kernel-level impact means affected systems should still be updated through normal or accelerated maintenance cycles.

How an attack unfolds

An attacker needs local access with sufficient ability to interact with an F2FS filesystem, such as using an existing mounted F2FS volume or creating/mounting one where policy allows it. The attacker triggers writeback activity involving checkpoint data and then races that activity against filesystem unmount or teardown. In the vulnerable sequence, the write completion path decrements the F2FS writeback page count and wakes the checkpoint waiter, allowing unmount cleanup to proceed and clear node_inode. The write completion path can then continue and check whether a folio belongs to the warm node list, dereferencing state that has already been cleared. The most direct result is a kernel oops or panic, causing system denial of service; in more advanced scenarios, a kernel memory lifetime bug could be investigated for privilege escalation, though no mature exploit is indicated by the supplied intelligence.

How to fix it

Upgrade to a Linux kernel version from the relevant distribution or vendor that includes the F2FS fix moving the f2fs_in_warm_node_list() check before decrementing sbi->nr_pages[F2FS_WB_CP_DATA] in f2fs_write_end_io(). No exact fixed package versions were provided, so use vendor advisories, kernel changelogs, and distribution security trackers for the affected kernel line. Where immediate patching is not possible, reduce exposure by disabling or avoiding F2FS on systems that do not require it, preventing unprivileged filesystem mounts, restricting access to loop devices and removable media workflows, limiting container capabilities such as CAP_SYS_ADMIN, and ensuring local users cannot mount attacker-controlled F2FS images. Reboot into the patched kernel after installation; installing a kernel package alone is not sufficient if the system continues running the old kernel.

How to confirm the fix worked

Confirm the running kernel, not only the installed package, has been updated by checking uname -r and comparing it with the vendor-fixed kernel release. Review distribution kernel changelogs or source patches for the F2FS change in f2fs_write_end_io() that calls f2fs_in_warm_node_list() before dec_page_count(sbi, F2FS_WB_CP_DATA). Verify whether F2FS is present or in use with commands such as findmnt -t f2fs, mount | grep f2fs, lsmod | grep f2fs, and kernel configuration checks for CONFIG_F2FS_FS. Confirm unprivileged mount paths are restricted where mitigation is relied upon. Avoid validating by intentionally racing unmount/writeback on production systems; use vendor patch confirmation, kernel provenance, and non-production testing if needed.

Typical attack path

1. Obtain local execution on a Linux system running an affected kernel.
2. Identify whether F2FS support is enabled and whether an F2FS filesystem is mounted or can be mounted.
3. Generate F2FS checkpoint/writeback activity on the target filesystem.
4. Trigger or race unmount/teardown while F2FS write completion callbacks are still executing.
5. Cause the vulnerable ordering in the F2FS write completion path, leading to dereference of cleared filesystem state.
6. Achieve a kernel crash/host denial of service, or attempt further kernel exploitation if reliable memory corruption primitives are developed.

How to detect it

Look for evidence of kernel crashes, oops messages, or panic events involving F2FS writeback, checkpointing, or unmount operations. Primary sources include journalctl -k, dmesg, /var/log/kern.log, /var/log/messages, systemd-coredump metadata, kdump/vmcore files, hypervisor reset logs, and endpoint telemetry showing unexpected reboots. Search for stack traces containing f2fs_write_end_io, f2fs_in_warm_node_list, is_node_folio, dec_page_count, kill_f2fs_super, f2fs_put_super, f2fs_write_checkpoint, or F2FS_WB_CP_DATA. Correlate crash timing with audit logs for mount, umount, losetup, removable media insertion, container launches with elevated privileges, or local user activity that could create or tear down F2FS filesystems. Exploitation is likely to leave crash artifacts rather than network indicators; absence of logs may occur if the system panics before flushing buffers, so retain kdump/vmcore where available.

• f2fs_write_end_io
• f2fs_in_warm_node_list
• is_node_folio
• F2FS_WB_CP_DATA
• dec_page_count(sbi, F2FS_WB_CP_DATA)
• kill_f2fs_super
• f2fs_put_super
• f2fs_write_checkpoint
• f2fs_wait_on_all_pages
• node_inode is NULL
• NULL pointer dereference
• BUG: kernel NULL pointer dereference
• Kernel panic - not syncing
• Oops:
• RIP: f2fs_write_end_io
• RIP: f2fs_in_warm_node_list
• RIP: is_node_folio
• EXT4-fs error

What your security team should do

• Inventory Linux systems that use F2FS or have F2FS enabled, prioritizing endpoints, appliances, mobile/embedded Linux devices, and systems that allow removable media or user-controlled mounts.
• Apply vendor kernel updates that include the F2FS fix and schedule reboots to ensure the patched kernel is active.
• If patching is delayed, disable F2FS where not needed and restrict unprivileged mounts, loop devices, removable media automounting, and container privileges that could permit filesystem mounting.
• Monitor kernel logs and crash telemetry for F2FS-related oops/panic events, especially around unmount, checkpoint, or writeback activity.
• Treat unexplained kernel crashes on systems with local multi-user access as potentially security-relevant and preserve kdump/vmcore artifacts for analysis.
• Because the provided EPSS is low, KEV is false, and no exploit maturity is reported, prioritize this behind actively exploited remote vulnerabilities but ahead of routine low-impact bugs on systems where F2FS is exposed to local users.