CVE-2025-37999 in Linux
Summary
by MITRE • 05/29/2025
In the Linux kernel, the following vulnerability has been resolved:
fs/erofs/fileio: call erofs_onlinefolio_split() after bio_add_folio()
If bio_add_folio() fails (because it is full), erofs_fileio_scan_folio() needs to submit the I/O request via erofs_fileio_rq_submit() and allocate a new I/O request with an empty `struct bio`. Then it retries the bio_add_folio() call.
However, at this point, erofs_onlinefolio_split() has already been called which increments `folio->private`; the retry will call erofs_onlinefolio_split() again, but there will never be a matching erofs_onlinefolio_end() call. This leaves the folio locked forever and all waiters will be stuck in folio_wait_bit_common().
This bug has been added by commit ce63cb62d794 ("erofs: support unencoded inodes for fileio"), but was practically unreachable because there was room for 256 folios in the `struct bio` - until commit 9f74ae8c9ac9 ("erofs: shorten bvecs[] for file-backed mounts") which
reduced the array capacity to 16 folios.
It was now trivial to trigger the bug by manually invoking readahead from userspace, e.g.:
posix_fadvise(fd, 0, st.st_size, POSIX_FADV_WILLNEED);
This should be fixed by invoking erofs_onlinefolio_split() only after bio_add_folio() has succeeded. This is safe: asynchronous completions invoking erofs_onlinefolio_end() will not unlock the folio because erofs_fileio_scan_folio() is still holding a reference to be released by erofs_onlinefolio_end() at the end.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 11/28/2025
The vulnerability described in CVE-2025-37999 represents a critical race condition and resource management flaw within the Linux kernel's erofs (erofs filesystem) implementation. This issue manifests in the file I/O handling code where improper sequencing of operations leads to permanent folio locking and system resource exhaustion. The flaw specifically affects the erofs filesystem's ability to handle file-backed I/O operations through the fileio subsystem, creating a scenario where kernel threads become indefinitely blocked waiting for folio unlock operations that never occur.
The technical root cause stems from the improper ordering of function calls within the erofs_fileio_scan_folio() function where erofs_onlinefolio_split() is invoked before bio_add_folio() is executed. When bio_add_folio() fails due to buffer capacity limits, the code path attempts to submit the pending I/O request and allocate a new bio structure for retry operations. However, because erofs_onlinefolio_split() has already been called and incremented the folio's private counter, subsequent retries result in duplicate split operations without corresponding cleanup calls. This creates a fundamental imbalance in the reference counting mechanism that governs folio locking semantics within the Linux kernel's memory management subsystem.
The operational impact of this vulnerability is severe as it results in indefinite blocking of I/O operations and thread starvation within the kernel's file I/O subsystem. All processes attempting to access files backed by the affected erofs filesystem will experience complete blocking, leading to system unresponsiveness and potential denial of service conditions. The vulnerability's trigger mechanism is particularly concerning as it can be easily activated through standard userspace POSIX_FADV_WILLNEED advisory calls, making it exploitable through legitimate system operations rather than requiring specialized attack vectors. This aligns with ATT&CK technique T1499.004 for resource exhaustion and represents a classic case of improper resource management as classified by CWE-404.
The vulnerability was introduced by commit ce63cb62d794 which added support for unencoded inodes in the fileio subsystem, but remained practically dormant due to sufficient buffer capacity in the original bio structure implementation. The issue became exploitable when commit 9f74ae8c9ac9 reduced the bvecs[] array capacity from 256 to 16 folios, dramatically increasing the probability of bio_add_folio() failures during normal I/O operations. This reduction in capacity effectively transformed what was previously an edge case into a readily reproducible condition that can be triggered through simple readahead operations. The fix implemented addresses the core issue by reordering the function calls to ensure erofs_onlinefolio_split() is only invoked after bio_add_folio() has successfully completed, maintaining proper reference counting and preventing the accumulation of unmatched split operations.
Mitigation strategies for this vulnerability require immediate kernel updates to include the corrected function call ordering that ensures proper resource management. System administrators should prioritize patching affected systems as the vulnerability can lead to complete system unresponsiveness and requires kernel-level fixes to resolve. The fix maintains the existing asynchronous completion semantics while ensuring proper reference counting through the folio locking mechanism, preventing the accumulation of references that would otherwise prevent folio unlocking. Organizations should also implement monitoring for unusual I/O patterns and system responsiveness issues that might indicate the presence of this vulnerability in unpatched systems, particularly in environments heavily reliant on erofs filesystems for file storage operations.