CVE-2026-31714

What it actually does

This is a local Linux kernel availability flaw in the F2FS filesystem rename path. A missing f2fs_free_filename() call after f2fs_setup_filename() in f2fs_rename() leaks a small kernel heap allocation during affected rename operations. A local authenticated user who can perform file rename operations on an affected mounted F2FS filesystem can repeatedly trigger the leak, gradually consuming kernel memory and potentially causing system-wide memory pressure, out-of-memory kills, degraded service, or a crash. The issue does not provide direct confidentiality or integrity impact and is not remotely exploitable under the published CVSS vector.

Why it matters to the business

Systems using affected Linux kernels with F2FS filesystems may be vulnerable to local denial of service: an unprivileged or low-privileged user, container workload, or compromised local process with access to writable F2FS storage could degrade or disrupt host availability. The EPSS score is very low, there is no known CISA KEV listing, no known ransomware use, and no public exploit maturity reported, so broad internet-scale exploitation is unlikely; however, multi-user Linux hosts, embedded devices, Android-derived platforms, and systems relying on F2FS for writable storage should still prioritize kernel updates during normal patch cycles because availability impact can be high when the vulnerable code path is reachable.

How an attack unfolds

An attacker first obtains local code execution or an account on a Linux system running an affected kernel. They then identify or access a writable F2FS-mounted filesystem. By repeatedly invoking rename operations, such as through renameat2(), in the vulnerable F2FS path, the kernel allocates filename-related memory through fscrypt_setup_filename() without releasing it in the affected control flow. Each operation leaks a small kernel object. Repeating the operation at scale can accumulate unreclaimable kernel memory consumption until the host experiences memory pressure, OOM events, service terminations, or a system hang/reboot. Exploitation is local, requires privileges sufficient to create or rename files in the target filesystem, and is primarily useful for denial of service rather than data theft or privilege escalation.

How to fix it

Apply a vendor-supplied Linux kernel update that includes the F2FS fix adding the missing filename cleanup in f2fs_rename(). No exact fixed package versions were provided in the input, so use the fixed kernel versions published by the relevant distribution, device vendor, or upstream stable kernel branch. Reboot into the updated kernel after installation and verify that the running kernel, not only the installed package, is fixed. If immediate patching is not possible, reduce exposure by limiting local shell access, restricting write access to F2FS-mounted filesystems, moving untrusted workloads off F2FS-backed writable storage where feasible, enforcing resource controls for untrusted users and containers, and monitoring for memory pressure or excessive rename activity. These mitigations reduce exploitability but do not correct the underlying kernel bug.

How to confirm the fix worked

Confirm whether systems are exposed by checking the running kernel version, distribution kernel advisory status, and whether F2FS support is enabled or F2FS filesystems are mounted. Use commands such as uname -a, package manager kernel version checks, findmnt -t f2fs, mount | grep f2fs, and zgrep F2FS /proc/config.gz where available. After remediation, verify that the system has booted into the patched kernel and that vendor advisories mark the installed kernel as fixed. For functional validation in a non-production test environment only, repeated rename operations on an F2FS filesystem should no longer produce kmemleak reports referencing fscrypt_setup_filename(), f2fs_setup_filename(), or f2fs_rename(). Avoid running stress reproducers on production systems because they may intentionally create memory pressure.

Typical attack path

1. Gain local execution on a Linux system through a user account, compromised service, container escape prerequisite, or existing foothold.
2. Confirm that an affected kernel is running and that a writable F2FS filesystem is mounted.
3. Create files or directory entries in a location where the attacker has write permissions.
4. Repeatedly invoke rename or renameat2 operations that exercise the vulnerable f2fs_rename() path.
5. Cause repeated kernel heap allocations that are not freed.
6. Continue the loop until kernel memory pressure causes degraded performance, OOM-killer activity, service disruption, crash, or reboot.

How to detect it

Retrospective detection should focus on host telemetry because exploitation is local and leaves kernel/resource symptoms rather than network indicators. Review kernel logs, journald, dmesg, crash logs, and centralized syslog for memory leak reports, OOM-killer events, hangs, or panics around F2FS rename activity. If kmemleak is enabled, look for reports with stack traces containing fscrypt_setup_filename(), f2fs_setup_filename(), f2fs_rename(), vfs_rename(), filename_renameat2(), or __x64_sys_renameat2(). Check auditd, eBPF syscall tracing, EDR, or process accounting for unusually high rename, renameat, or renameat2 syscall rates from a user process, especially against F2FS mount points. Correlate spikes in rename activity with rising slab/kernel memory usage, OOM kills, service restarts, or host reboots. There are no known public threat actors, ransomware campaigns, or remote exploitation indicators associated with this vulnerability in the provided data.

• BUG: memory leak
• f2fs_rename
• f2fs_rename2
• f2fs_setup_filename
• f2fs_free_filename
• fscrypt_setup_filename
• vfs_rename
• filename_renameat2
• __x64_sys_renameat2
• Out of memory
• oom-killer
• Killed process
• kmemleak_alloc_recursive
• unreferenced object

What your security team should do

• Inventory Linux systems that use F2FS, especially embedded, mobile, edge, appliance, and multi-user systems with writable F2FS mounts.
• Patch affected kernels through the appropriate OS or vendor channel and reboot into the fixed kernel.
• Prioritize remediation for systems where untrusted users, containers, CI jobs, or application workloads can write to F2FS filesystems.
• If patching is delayed, restrict local access and write permissions to F2FS mounts and apply user/container memory and process limits where practical.
• Monitor kernel logs for kmemleak, OOM-killer, and crash events that reference F2FS rename paths.
• Review auditd, eBPF, or EDR telemetry for unusual high-volume rename/renameat2 activity against F2FS mount points.
• Do not rely on network perimeter controls as the primary mitigation; exploitation is local and occurs through filesystem syscalls.
• Track distribution and upstream stable kernel advisories because fixed package versions vary by vendor and branch.