Message-ID: <2025052903-CVE-2025-37999-cb71@gregkh>
Date: Thu, 29 May 2025 15:16:06 +0200
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: linux-cve-announce@...r.kernel.org
Cc: Greg Kroah-Hartman <gregkh@...nel.org>
Subject: CVE-2025-37999: fs/erofs/fileio: call erofs_onlinefolio_split() after bio_add_folio()

From: Greg Kroah-Hartman <gregkh@...nel.org>

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.

The Linux kernel CVE team has assigned CVE-2025-37999 to this issue.


Affected and fixed versions
===========================

	Issue introduced in 6.12 with commit ce63cb62d794c98c7631c2296fa845f2a8d0a4a1 and fixed in 6.12.29 with commit 61e0fc3312309867e5a3495329dad0286d2a5703
	Issue introduced in 6.12 with commit ce63cb62d794c98c7631c2296fa845f2a8d0a4a1 and fixed in 6.14.7 with commit c26076197df348c84cc23e5962d61902e072a0f5
	Issue introduced in 6.12 with commit ce63cb62d794c98c7631c2296fa845f2a8d0a4a1 and fixed in 6.15 with commit bbfe756dc3062c1e934f06e5ba39c239aa953b92

Please see https://www.kernel.org for a full list of currently supported
kernel versions by the kernel community.

Unaffected versions might change over time as fixes are backported to
older supported kernel versions.  The official CVE entry at
	https://cve.org/CVERecord/?id=CVE-2025-37999
will be updated if fixes are backported, please check that for the most
up to date information about this issue.


Affected files
==============

The file(s) affected by this issue are:
	fs/erofs/fileio.c


Mitigation
==========

The Linux kernel CVE team recommends that you update to the latest
stable kernel version for this, and many other bugfixes.  Individual
changes are never tested alone, but rather are part of a larger kernel
release.  Cherry-picking individual commits is not recommended or
supported by the Linux kernel community at all.  If however, updating to
the latest release is impossible, the individual changes to resolve this
issue can be found at these commits:
	https://git.kernel.org/stable/c/61e0fc3312309867e5a3495329dad0286d2a5703
	https://git.kernel.org/stable/c/c26076197df348c84cc23e5962d61902e072a0f5
	https://git.kernel.org/stable/c/bbfe756dc3062c1e934f06e5ba39c239aa953b92

Powered by blists - more mailing lists