CVE-2025-37999

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.
Configurations

Configuration 1 (hide)

OR cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:6.15:rc1:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:6.15:rc2:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:6.15:rc3:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:6.15:rc4:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:6.15:rc5:*:*:*:*:*:*

History

14 Nov 2025, 16:48

Type Values Removed Values Added
CPE cpe:2.3:o:linux:linux_kernel:6.15:rc4:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:6.15:rc5:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:6.15:rc2:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:6.15:rc3:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:6.15:rc1:*:*:*:*:*:*
First Time Linux
Linux linux Kernel
CVSS v2 : unknown
v3 : unknown
v2 : unknown
v3 : 5.5
CWE NVD-CWE-noinfo
References () https://git.kernel.org/stable/c/61e0fc3312309867e5a3495329dad0286d2a5703 - () https://git.kernel.org/stable/c/61e0fc3312309867e5a3495329dad0286d2a5703 - Patch
References () https://git.kernel.org/stable/c/bbfe756dc3062c1e934f06e5ba39c239aa953b92 - () https://git.kernel.org/stable/c/bbfe756dc3062c1e934f06e5ba39c239aa953b92 - Patch
References () https://git.kernel.org/stable/c/c26076197df348c84cc23e5962d61902e072a0f5 - () https://git.kernel.org/stable/c/c26076197df348c84cc23e5962d61902e072a0f5 - Patch
Summary
  • (es) En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: fs/erofs/fileio: llamar a erofs_onlinefolio_split() después de bio_add_folio(). Si bio_add_folio() falla (porque está lleno), erofs_fileio_scan_folio() debe enviar la solicitud de E/S mediante erofs_fileio_rq_submit() y asignar una nueva solicitud de E/S con un `struct bio` vacío. Luego, vuelve a intentar la llamada a bio_add_folio(). Sin embargo, en este punto, ya se ha llamado a erofs_onlinefolio_split(), lo que incrementa `folio->private`; el reintento llamará a erofs_onlinefolio_split() de nuevo, pero nunca habrá una llamada erofs_onlinefolio_end() coincidente. Esto deja el folio bloqueado para siempre y todos los que esperan quedarán atascados en folio_wait_bit_common(). Este error se añadió con el commit ce63cb62d794 ("erofs: compatibilidad con inodos no codificados para fileio"), pero era prácticamente imposible de solucionar porque había espacio para 256 folios en la estructura `struct bio`, hasta el commit 9f74ae8c9ac9 ("erofs: acortar bvecs[] para montajes con respaldo de archivo"), que redujo la capacidad del array a 16 folios. Ahora era fácil activar el error invocando manualmente la lectura anticipada desde el espacio de usuario, por ejemplo: posix_fadvise(fd, 0, st.st_size, POSIX_FADV_WILLNEED); Esto debería solucionarse invocando erofs_onlinefolio_split() solo después de que bio_add_folio() se haya ejecutado correctamente. Esto es seguro: las finalizaciones asincrónicas que invocan erofs_onlinefolio_end() no desbloquearán el folio porque erofs_fileio_scan_folio() todavía contiene una referencia que erofs_onlinefolio_end() liberará al final.

29 May 2025, 14:15

Type Values Removed Values Added
New CVE

Information

Published : 2025-05-29 14:15

Updated : 2025-11-14 16:48


NVD link : CVE-2025-37999

Mitre link : CVE-2025-37999

CVE.ORG link : CVE-2025-37999


JSON object : View

Products Affected

linux

  • linux_kernel