CVE-2025-38163

What it actually does

In f2fs, inconsistent sbi->total_valid_block_count versus inode-mapped blocks on a fuzzed image triggers a kernel BUG/panic in dec_valid_block_count instead of logging and setting fsck flag.

Why it matters to the business

Potential denial-of-service crashes on any Linux system using the f2fs filesystem when presented with malicious or corrupted images; widespread Linux kernel prevalence increases exposure surface though exploitation remains unconfirmed in the wild.

How an attack unfolds

An attacker supplies a fuzzed f2fs image; the victim mounts it and performs file operations such as creat or truncate that reach f2fs_truncate_inode_blocks, exposing the block-count inconsistency and forcing a kernel panic.

How to fix it

Upgrade to a kernel containing commit 49bc7bf38e42cfa642787e947f5721696ea73ac3 or the Mageia SDL12 package 1.2.15-26.1.mga8; rebuild and reboot all affected systems.

How to confirm the fix worked

Confirm kernel git commit or package version matches fixed release; replay syzbot-style fuzzed-image truncate workloads and verify absence of the f2fs.h:2521 BUG.

Typical attack path

1. Craft or obtain fuzzed f2fs filesystem image
2. Mount the image on a vulnerable Linux kernel
3. Trigger file creation or truncation via open/creat/truncate syscalls
4. Reach dec_valid_block_count with mismatched counts causing BUG

How to detect it

Search kernel logs and crash reports for the exact BUG line fs/f2fs/f2fs.h:2521 or the function dec_valid_block_count during f2fs truncate paths; correlate with recent mount of external f2fs volumes.

• kernel BUG at fs/f2fs/f2fs.h:2521
• dec_valid_block_count+0x3b2/0x3c0
• f2fs_truncate_data_blocks_range
• f2fs_do_truncate_blocks

What your security team should do

• Prioritize kernel package updates on all f2fs-using hosts within standard patching windows
• Add f2fs mount restrictions or read-only policies where untrusted images may be processed
• Include the f2fs BUG signature in kernel oops monitoring rules