VulnerabilityPublished 29 May 2025

CVE-2025-37999: Linux kernel · fs/erofs/fileio: call erofs_onlinefolio_split() after bio_add_folio()

Affects Linux kernelSource CVE Database V5

Not known to be exploited.

Data as of 26 Oct 2026, 17:16 UTC

Severity

High

Rated High by the CNA (Linux) · No CVSS score from NVD or the CNA

EPSS: 0.1% chance of exploitation in 30 days – higher than 8% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.

Exploitation evidence

Disclosed: evidence found.
CVE published 29 May 2025
Detectable: no evidence on record.
No public nuclei template indexed
Weaponised: no evidence on record.
No public exploit code indexed in Metasploit or Exploit-DB
Exploited in the wildExploited: no evidence on record.
Not in CISA KEV and no source reports exploitation
Observed by OffSeq MirageSeen by Mirage: no evidence on record.
No attack traffic recorded by OffSeq Mirage sensors

A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 26 Oct 2026.

Disclosed: The CVE record is public on cve.org. Its publication is t = 0.
Detectable: A public nuclei template can find exposed instances, for defenders and attackers alike.
Weaponised: Public exploit code exists in Metasploit or Exploit-DB, or CISA SSVC or the CVSS exploit maturity reports a public proof of concept.
Exploited in the wild: CISA KEV lists it, CISA SSVC rates exploitation active, or a source reports attacks.
Observed by OffSeq Mirage: OffSeq Mirage honeypot sensors recorded attack traffic for this CVE, or found exposed hosts without attack traffic.

Moments are spaced evenly, not to scale; a dashed line marks a gap of six months or more. Deltas count from t = 0. Sources that give only a date (CISA KEV, Exploit-DB, or a time of exactly 00:00Z) read “same day” rather than hours. Metasploit modules carry the flaw’s disclosure date, not their release date, and nuclei templates carry no date, so both appear above but not on the timeline.

What to do

AI-suggested

European organizations should prioritize updating Linux kernels to versions that include the fix for CVE-2025-37999. Kernel maintainers have corrected the code to call erofs_onlinefolio_split() only after bio_add_folio() succeeds, preventing folio lockups. Until patches are applied, administrators should monitor systems using EROFS mounts for symptoms such as hung processes or I/O stalls, especially following readahead operations. Limiting or disabling aggressive readahead on EROFS filesystems can reduce exposure. Additionally, auditing and restricting user-space applications that perform manual readahead (e.g., via posix_fadvise()) on EROFS volumes can mitigate risk. For environments using containerization or virtualization, ensure host kernels are patched since guest kernels may rely on host I/O. Implementing robust monitoring and alerting for I/O hangs and process stalls will aid in early detection. Finally, organizations should maintain an inventory of systems using EROFS to prioritize patching and risk assessment.

Description

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.

Impact

For European organizations relying on Linux systems with EROFS-mounted filesystems, this vulnerability poses a risk of local denial of service. Applications or services performing aggressive readahead or asynchronous I/O on EROFS volumes could trigger the bug, causing processes to hang indefinitely. This can degrade system availability, impact critical services, and complicate troubleshooting. While the vulnerability does not appear to allow privilege escalation or remote code execution, the resulting DoS can disrupt operations, especially in environments with automated file access patterns or containerized workloads using EROFS. Given Linux's widespread use in European data centers, cloud infrastructure, and embedded devices, the impact could be significant in sectors such as telecommunications, finance, and public services where uptime is critical. The lack of known exploits reduces immediate risk, but the ease of triggering the bug via standard system calls suggests potential for exploitation in unpatched systems.

Summary

CVE-2025-37999 is a vulnerability in the Linux kernel's EROFS (Enhanced Read-Only File System) file I/O subsystem. The flaw arises from improper handling of bio_add_folio() failures during asynchronous I/O operations. Specifically, when bio_add_folio() fails because the bio structure is full, the code attempts to submit the current I/O request and allocate a new bio structure before retrying bio_add_folio(). However, erofs_onlinefolio_split() is called prematurely before confirming bio_add_folio() success, which increments a reference counter (folio->private) without a corresponding decrement. This results in the folio remaining locked indefinitely, causing any processes waiting on this folio to hang in folio_wait_bit_common(). The root cause was introduced by a commit that added support for unencoded inodes but was practically unreachable due to a large bio capacity (256 folios). A subsequent commit reduced the bio capacity to 16 folios, making it trivial to trigger the bug, for example by invoking readahead from userspace via posix_fadvise(). The fix involves calling erofs_onlinefolio_split() only after bio_add_folio() succeeds, ensuring proper reference counting and unlocking of folios. This vulnerability can cause a denial of service (DoS) by hanging processes that access EROFS-mounted filesystems under specific conditions. No known exploits are currently reported in the wild, and the vulnerability affects Linux kernel versions containing the specified commits.

References

Community reviews

Loading reviews…

Exploitation evidence

What to do

Description

AI analysisMachine-generated, updated 8 Jul 2025, 03:28 UTC

Technical details

References

Community reviews

Related threats