CVE-2026-92500 in Linux
Resumen
por VulDB • 2026-09-18
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad:
ext4: usar fsdata para rastrear el estado de escritura de datos en línea y corregir una condición de carrera (race condition)
En lugar de verificar el estado del inode activo (`ext4_has_inline_data(inode)` y `ext4_test_inode_state(inode, EXT4_STATE_MAY_INLINE_DATA)`) en los controladores de `write_end`, se utiliza el parámetro `fsdata` de las operaciones del espacio de direcciones para pasar explícitamente hacia abajo el estado en que `write_begin` preparó la escritura.
Un hilo concurrente (como `ext4_page_mkwrite()`) puede convertir los datos en línea a un extent entre `write_begin` y `write_end`. Si esto ocurre, los controladores de `write_end` anteriormente omitían la ruta de `write_end` para datos en línea y derivaban hacia la lógica de `write_end` basada en extents. Sin embargo, dado que nunca se asignaron búferes de bloques en `write_begin`, esto resultó en desreferencias a punteros NULL o pérdida de datos porque `folio_buffers(folio)` era NULL.
Se define `EXT4_WRITE_DATA_INLINE (4)` como una bandera bit a bit (Bit 2), tratando `fsdata` como banderas bitwise en lugar de enums mutuamente excluyentes para mantener independientes los estados de la ruta de escritura. Se comunica este estado mediante `fsdata`: 1) `ext4_write_begin()` y `ext4_da_write_begin()` establecen el bit `EXT4_WRITE_DATA_INLINE` en *fsdata mediante OR bitwise cuando una escritura en línea se prepara correctamente. 2) Al entrar, `ext4_write_begin()` borra el bit `EXT4_WRITE_DATA_INLINE` para manejar de forma segura los reintentos del VFS (donde `generic_perform_write()` omite la inicialización de fsdata en su salto de reintento). 3) Los controladores de write_end realizan un AND bitwise para verificar si está establecido el bit `EXT4_WRITE_DATA_INLINE` e invocan al auxiliar correspondiente de write_end.
Además, durante una escritura con búfer (`buffered write`), `ext4_write_inline_data_end()` adquiere el bloqueo xattr después de preparar la escritura. Si un fallo de página concurrente (`ext4_page_mkwrite()`) convierte los datos en línea a un extent después de que los controladores de write_end verifiquen el estado pero antes de que `ext4_write_inline_data_end()` adquiera el bloqueo de escritura xattr, la comprobación subsiguiente provocará una panic del kernel mediante `BUG_ON(!ext4_has_inline_data(inode))`.
Para mantener funcionando el historial de git y preservar la capacidad de bisectado limpio (`bisectability`), se reemplaza la verificación BUG_ON en ext4_write_inline_data_end() con un camino de reintento de manejo de errores graceful (sin fallos) en este mismo commit. Si los datos en línea se borran después de bloquear el xattr, liberamos de forma segura todos los recursos (liberando iloc.bh, desbloqueando/soltando el folio, deteniendo el controlador de transacción del journal activo) y devolvemos 0 (reintento VFS) para permitir que la ruta genérica de escritura reintente la operación de manera segura.
If you want to get best quality of vulnerability data, you may have to visit VulDB.