CVE-2025-40025: f2fs: fix to do sanity check on node footer for non inode dnode
In the Linux kernel, the following vulnerability has been resolved:
f2fs: fix to do sanity check on node footer for non inode dnode
As syzbot reported below:
------------[ cut here ]------------
kernel BUG at fs/f2fs/file.c:1243!
Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI
CPU: 0 UID: 0 PID: 5354 Comm: syz.0.0 Not tainted 6.17.0-rc1-syzkaller-00211-g90d970cade8e #0 PREEMPT(full)
RIP: 0010:f2fs_truncate_hole+0x69e/0x6c0 fs/f2fs/file.c:1243
Call Trace:
<TASK>
f2fs_punch_hole+0x2db/0x330 fs/f2fs/file.c:1306
f2fs_fallocate+0x546/0x990 fs/f2fs/file.c:2018
vfs_fallocate+0x666/0x7e0 fs/open.c:342
ksys_fallocate fs/open.c:366 [inline]
__do_sys_fallocate fs/open.c:371 [inline]
__se_sys_fallocate fs/open.c:369 [inline]
__x64_sys_fallocate+0xc0/0x110 fs/open.c:369
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f1e65f8ebe9
w/ a fuzzed image, f2fs may encounter panic due to it detects inconsistent
truncation range in direct node in f2fs_truncate_hole().
The root cause is: a non-inode dnode may has the same footer.ino and
footer.nid, so the dnode will be parsed as an inode, then ADDRS_PER_PAGE()
may return wrong blkaddr count which may be 923 typically, by chance,
dn.ofs_in_node is equal to 923, then count can be calculated to 0 in below
statement, later it will trigger panic w/ f2fs_bug_on(, count == 0 || ...).
count = min(end_offset - dn.ofs_in_node, pg_end - pg_start);
This patch introduces a new node_type NODE_TYPE_NON_INODE, then allowing
passing the new_type to sanity_check_node_footer in f2fs_get_node_folio()
to detect corruption that a non-inode dnode has the same footer.ino and
footer.nid.
Scripts to reproduce:
mkfs.f2fs -f /dev/vdb
mount /dev/vdb /mnt/f2fs
touch /mnt/f2fs/foo
touch /mnt/f2fs/bar
dd if=/dev/zero of=/mnt/f2fs/foo bs=1M count=8
umount /mnt/f2fs
inject.f2fs --node --mb i_nid --nid 4 --idx 0 --val 5 /dev/vdb
mount /dev/vdb /mnt/f2fs
xfs_io /mnt/f2fs/foo -c "fpunch 6984k 4k"
Security readout for executives and security teams
Plain-English summary
A corrupted or malicious F2FS filesystem image can confuse Linux kernel metadata handling and trigger a kernel panic during a hole-punch operation. This can crash the affected system. The supplied CVSS score is 7.8, but the demonstrated outcome is denial of service; broader confidentiality or integrity impact is not established by the provided evidence.
Executive priority
Prioritize systems that ingest external filesystem images, use removable F2FS media, or permit less-trusted local users. Patch through supported distribution channels. For systems without F2FS exposure, urgency is lower, but version status should still be documented because a kernel crash can materially affect availability.
Technical view
A non-inode direct node can have matching footer inode and node identifiers, causing F2FS to parse it as an inode. This produces an incorrect address count and may reach an invalid zero-count condition in f2fs_truncate_hole(), triggering a kernel BUG. The fix adds a non-inode node type and strengthens footer validation in f2fs_get_node_folio().
Likely exposure
Exposure is limited to Linux systems using or processing F2FS filesystems, particularly those that may mount corrupted or untrusted images. Local access and interaction with the malformed filesystem are indicated. The supplied affected-version data is ambiguous, so distribution-specific package status should be checked against the referenced stable-kernel fixes.
Exploitation context
The issue was found by syzbot using a fuzzed F2FS image. The provided record is not in KEV and supplies no evidence of active exploitation. It describes a local, low-complexity condition requiring low privileges and no user interaction, but does not demonstrate remote exploitation or reliable impact beyond a kernel panic.
Researcher notes
The supplied CVSS vector rates confidentiality, integrity, and availability impacts as high, although the narrative demonstrates only a panic. Treat broader impact as unconfirmed. Version metadata in the bundle is not sufficiently clear for an exact fixed-version statement; use the two stable-kernel commits as patch-presence anchors and consult downstream vendor guidance.
Mitigation direction
Install a vendor kernel release that incorporates the referenced upstream F2FS fix.
Check Linux distribution advisories and package changelogs for CVE-2025-40025 coverage.
Until updated, restrict mounting or processing of untrusted F2FS filesystem images.
Apply normal least-privilege controls around filesystem mounting and image ingestion.
Validation and detection
Inventory systems that enable, mount, or process F2FS filesystems.
Record running kernel and distribution package versions on exposed systems.
Confirm package source or changelogs include either referenced stable-kernel fix.
Use an authorized regression environment to confirm malformed metadata is rejected without a kernel panic.
Review kernel logs for F2FS corruption reports, BUG messages, or related panics.
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-2025-40025 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.
1CVSS vectors
3Timeline events
0ADP providers
3Source links
CVSS vector scores
1 official score
We collect every scored CVSS vector available in the official CNA and ADP containers. When more than one version is present, the table keeps the source vectors side by side instead of collapsing them into the highest score.