CVE-2025-38626

f2fs: fix to trigger foreground gc during f2fs_map_blocks() in lfs mode

published August 22, 2025

CVSS
—
EPSS
0%
Percentile
5.7
In the wild
Unconfirmed
What it is

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().

The record
Technical detail
CVSS
Not scored
CVSS v4.0
Not supplied
EPSS
0.00168 · 5.7th percentile
Published
2025-08-22T16:00Z
EPSS history
Timeline
  • 22 AUG 16:00Z
    f2fs: fix to trigger foreground gc during f2fs_map_blocks() in lfs mode
    cvelistv5