CVE-2025-38626

Medium · 5.5

CVSS

5.5

EPSS

0.2%

Published

Aug 22, 2025

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A flaw in the Linux kernel's handling of a specific file-system write mode can cause the entire system to crash under heavy file-writing loads.

Exploitation: Local Privilege
Attacker needs: Low Privilege
Complexity: Low
Impact: Denial Of Service
Component: OS kernel
Class: Denial of service
Remediation: Upgrade
Effort: Medium
Patch risk: Low

What it actually does

In LFS mode, f2fs_map_blocks() defers foreground GC until after block allocation begins; concurrent AIO/DIO/bufio writers performing OPU allocations exhaust space and hit a BUG in new_curseg().

Why it matters to the business

Workloads using f2fs with the lfs mount option can trigger kernel panics during heavy parallel writes, producing unexpected downtime on affected Linux systems.

How an attack unfolds

A local attacker mounts an f2fs volume with mode=lfs, then issues concurrent direct or asynchronous writes; the delayed GC check allows block allocation to outpace available segments, causing the kernel to panic.

How to fix it

Apply the fix present in commit f289690f50a01c3e085d87853392d5b7436a4cee (or the corresponding stable backport) and reboot affected systems; avoid the lfs mount option until patched.

How to confirm the fix worked

Confirm the running kernel contains commit f289690f50a01c3e085d87853392d5b7436a4cee; reproduce the panic with the generic/299 xfstest suite on an unpatched kernel and verify it no longer occurs after the update.

Typical attack path

Mount f2fs filesystem using the mode=lfs option
Launch multiple threads performing AIO, DIO, or buffered writes in parallel
Drive the filesystem into an out-of-space condition during aggressive OPU allocations
Trigger the BUG in new_curseg() inside f2fs_allocate_data_block()

How to detect it

Search kernel logs and crash dumps for the exact BUG line in fs/f2fs/segment.c together with the call trace containing f2fs_allocate_data_block and new_curseg; correlate with f2fs mounts using the lfs option.

kernel BUG at fs/f2fs/segment.c:2835
new_curseg+0x70f/0x720
f2fs_allocate_data_block+0x6f4/0xc50
f2fs_map_blocks+0x970/0x1550

What your security team should do

Identify all systems mounting f2fs with mode=lfs and schedule immediate patching
Add the fixed commit hash to kernel build and deployment pipelines
Monitor kernel logs for segment.c:2835 BUG reports until remediation is complete

The record

In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to trigger foreground gc during f2fs_map_blocks() in lfs mode w/ "mode=lfs" mount option, generic/299 will cause system panic as below: ------------[ cut here ]------------ kernel BUG at fs/f2fs/segment.c:2835! Call Trace: <TASK> f2fs_allocate_data_block+0x6f4/0xc50 f2fs_map_blocks+0x970/0x1550 f2fs_iomap_begin+0xb2/0x1e0 iomap_iter+0x1d6/0x430 __iomap_dio_rw+0x208/0x9a0 f2fs_file_write_iter+0x6b3/0xfa0 aio_write+0x15d/0x2e0 io_submit_one+0x55e/0xab0 __x64_sys_io_submit+0xa5/0x230 do_syscall_64+0x84/0x2f0 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0010:new_curseg+0x70f/0x720 The root cause of we run out-of-space is: in f2fs_map_blocks(), f2fs may trigger foreground gc only if it allocates any physical block, it will be a little bit later when there is multiple threads writing data w/ aio/dio/bufio method in parallel, since we always use OPU in lfs mode, so f2fs_map_blocks() does block allocations aggressively. In order to fix this issue, let's give a chance to trigger foreground gc in prior to block allocation in f2fs_map_blocks().

Affected packages

Ecosystem	Package	Introduced	Fixed
Debian:11	linux	0	No fix
Debian:12	linux	0	No fix
Debian:13	linux	0	No fix
Debian:14	linux	0	No fix
Debian:14	linux	0	6.16.3-1
Linux	Kernel	4.8.0	6.6.102
Mageia:9	kernel	0	6.6.105-1.mga9
Mageia:9	kernel-linus	0	6.6.105-1.mga9
Mageia:9	kmod-virtualbox	0	7.1.10-10.mga9
Mageia:9	kmod-xtables-addons	0	3.24-86.mga9
Mageia:9	mageia-repos	0	9-4.mga9
Mageia:9	meta-task	0	9-4.mga9