CVE-2025-38626 in Linux
Summary
by MITRE • 08/22/2025
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().
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 05/28/2026
The vulnerability CVE-2025-38626 represents a critical race condition and resource management flaw within the F2FS (Flash-Friendly File System) implementation of the Linux kernel. This issue specifically manifests when the file system is mounted with the "mode=lfs" (log-structured file system) option, which is designed for optimal performance on flash storage devices. The flaw stems from improper foreground garbage collection triggering mechanisms during block allocation operations, leading to system panics and potential data corruption scenarios.
The technical root cause of this vulnerability lies in the asynchronous nature of block allocation within the f2fs_map_blocks() function when operating in LFS mode. During parallel I/O operations using aio, dio, or bufio methods, multiple threads can simultaneously request block allocations, creating a scenario where foreground garbage collection is delayed until after block allocation has already occurred. This delay results in a critical resource exhaustion condition where the system runs out of available space, ultimately triggering a kernel BUG at fs/f2fs/segment.c:2835. The call trace demonstrates the execution path leading to the panic, with the failure occurring in the new_curseg function, indicating segment management failure during the allocation process.
This vulnerability directly maps to CWE-476, representing a NULL pointer dereference or resource exhaustion issue, and aligns with ATT&CK technique T1499.001 for resource exhaustion attacks. The operational impact is severe as it can cause complete system crashes and data loss during concurrent write operations, particularly affecting systems running high I/O workloads on flash-based storage. The issue is particularly dangerous in production environments where multiple applications might be performing parallel writes to F2FS volumes with LFS mode enabled, potentially leading to denial of service conditions that could compromise entire systems.
The fix implemented addresses this by modifying the f2fs_map_blocks() function to proactively trigger foreground garbage collection before block allocation occurs, rather than waiting for allocation to complete. This change ensures that sufficient space is available in the file system before attempting to allocate new blocks, preventing the out-of-space conditions that trigger the kernel panic. The solution follows established best practices for memory management and resource allocation in concurrent systems, ensuring that foreground garbage collection is properly scheduled to maintain system stability. This mitigation aligns with the principle of proactive resource management and prevents the cascading failure conditions that occur when system resources become exhausted during high-concurrency write operations. The fix maintains backward compatibility while strengthening the file system's resilience under stress conditions.