CVE-2026-31714: f2fs: fix to avoid memory leak in f2fs_rename()
In the Linux kernel, the following vulnerability has been resolved:
f2fs: fix to avoid memory leak in f2fs_rename()
syzbot reported a f2fs bug as below:
BUG: memory leak
unreferenced object 0xffff888127f70830 (size 16):
comm "syz.0.23", pid 6144, jiffies 4294943712
hex dump (first 16 bytes):
3c af 57 72 5b e6 8f ad 6e 8e fd 33 42 39 03 ff <.Wr[...n..3B9..
backtrace (crc 925f8a80):
kmemleak_alloc_recursive include/linux/kmemleak.h:44 [inline]
slab_post_alloc_hook mm/slub.c:4520 [inline]
slab_alloc_node mm/slub.c:4844 [inline]
__do_kmalloc_node mm/slub.c:5237 [inline]
__kmalloc_noprof+0x3bd/0x560 mm/slub.c:5250
kmalloc_noprof include/linux/slab.h:954 [inline]
fscrypt_setup_filename+0x15e/0x3b0 fs/crypto/fname.c:364
f2fs_setup_filename+0x52/0xb0 fs/f2fs/dir.c:143
f2fs_rename+0x159/0xca0 fs/f2fs/namei.c:961
f2fs_rename2+0xd5/0xf20 fs/f2fs/namei.c:1308
vfs_rename+0x7ff/0x1250 fs/namei.c:6026
filename_renameat2+0x4f4/0x660 fs/namei.c:6144
__do_sys_renameat2 fs/namei.c:6173 [inline]
__se_sys_renameat2 fs/namei.c:6168 [inline]
__x64_sys_renameat2+0x59/0x80 fs/namei.c:6168
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0xe2/0xf80 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
The root cause is in commit 40b2d55e0452 ("f2fs: fix to create selinux
label during whiteout initialization"), we added a call to
f2fs_setup_filename() without a matching call to f2fs_free_filename(),
fix it.
Security readout for executives and security teams
Plain-English summary
This is a Linux kernel memory leak in the F2FS filesystem rename path. It was found by syzbot and fixed upstream. The business risk appears most relevant to systems that use F2FS; the public record does not provide CVSS, impact scoring, or evidence of active exploitation.
Executive priority
Treat this as a targeted kernel maintenance item, not an emergency, unless critical systems use F2FS. The absence of CVSS and exploitation evidence lowers urgency, but kernel memory leaks can affect reliability and should be remediated through normal patch governance.
Technical view
In f2fs_rename(), a call to f2fs_setup_filename() introduced by a prior SELinux whiteout initialization change lacked the matching f2fs_free_filename() cleanup. That leaves allocated filename state unreferenced during rename handling. The issue is documented as a memory leak and linked to multiple Linux stable fixes.
Likely exposure
Exposure is likely limited to Linux systems running affected kernel builds with F2FS in use, especially where rename operations can be triggered. The source bundle lists affected kernel commits and versions, but the version metadata is incomplete enough that fleet validation should rely on vendor kernel advisories and fixed build mapping.
Exploitation context
The bundle cites a syzbot report and says KEV is false. No source in the bundle claims active exploitation, public weaponization, privilege escalation, remote exploitation, or a named attacker scenario.
Researcher notes
The root cause is specifically an unmatched allocation/free path in F2FS filename setup during rename. Sources do not establish exploitability beyond memory leakage. Avoid assuming broader kernel compromise without additional vendor analysis, crash evidence, or privilege boundary details.
Mitigation direction
Identify Linux hosts using F2FS or kernels built with F2FS support.
Map running kernel builds against vendor advisories for CVE-2026-31714.
Apply kernel updates containing the referenced stable fixes when available.
Prioritize internet-facing or multi-tenant systems if F2FS is present.
If no vendor update exists, monitor vendor guidance and reduce untrusted filesystem access.
Validation and detection
Inventory kernel versions and distribution patch levels across Linux assets.
Check whether F2FS filesystems are mounted or supported in deployed kernels.
Confirm vendor advisories include the upstream stable fix for CVE-2026-31714.
Review kernel changelogs for f2fs_rename() memory leak fixes.
Monitor memory leak or kernel stability signals on F2FS systems.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cve · low confidence lookup
CVE-2026-31714 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
0CVSS vectors
3Timeline events
0ADP providers
6Source links
Vulnerability timeline
Timeline events are normalized from CVE metadata, CNA source timelines, ADP timelines, and KEV metadata when present.
CVE reservedCVE Program
The CVE ID was reserved by the assigning CNA.
CVE publishedCVE Program
The CVE record was published.
May 1, 2026, 13:56 UTC (UTC+00:00)
CVE updatedCVE Program
The CVE record metadata indicates this as the latest update time.