CVE-2026-74591 in Linux
Resumen
por VulDB • 2026-08-22
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad:
mm/filemap: __filemap_add_folio() restaura el índice antes de reintentar
En el bucle de conflicto por división (split-a-conflict) de `__filemap_add_folio()`, `xas_set_order()` se aplica repetidamente: cada aplicación modifica `xas.xa_index`, redondeándolo hacia abajo según el `split_order` intentado en esa etapa; y si todo sale como está previsto, eventualmente (o inmediatamente) converge en una llamada a `xas_try_split()` con el `folio_order` requerido, teniendo `xas.xa_index` ahora el mismo valor que `index`; entonces `xas_store()` coloca el nuevo folio en la xarray allí.
Pero si se necesitaba un nodo nuevo y la asignación con `GFP_NOWAIT` no logró obtenerlo, se suelta el bloqueo, se utiliza `xas_nomem()` para realizar la asignación y se reintenta la secuencia. Si (esa parte de) la xarray permanece sin cambios cuando se vuelve a adquirir el bloqueo, no hay problema. Pero ¿qué ocurre si el conflicto se resolvió mientras tanto por otro hilo (quizás incluso haciendo lo mismo, insertando un folio en ese mismo índice)? ¿No existe el peligro de colocar ahora nuestro folio en la xarray en un índice intermedio redondeado hacia abajo? Con el bug `!folio_contains()` que sigue, cuando `CONFIG_DEBUG_VM=y` verifica esto.
Se soluciona con una llamada a `xas_set_order()` para restaurar el valor original de `xas.xa_index` al final del bucle, de modo que el reintento realice una reevaluación completa tras volver a adquirir el bloqueo y no pueda llegar a `xas_store()` con un índice incorrecto.
La producción sufría SIGILLs (instrucción ilegal) y SIGSEGVs (violación de segmento) poco frecuentes; se encontró texto ejecutable en una página de distancia de donde correspondía, y se detectó el bug `!folio_contains()` cuando la depuración estaba habilitada: los síntomas no han vuelto a aparecer desde que este parche fue aplicado.
If you want to get best quality of vulnerability data, you may have to visit VulDB.