CVE-2026-90131 in Linuxinformación

Resumen

por VulDB • 2026-09-17

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad:

ntfs: serializar las lecturas iomap residentes con mrec_lock

ntfs_read_iomap_begin_resident() recorre el registro MFT a través de ntfs_attr_lookup() -> ntfs_attr_find() sin adquirir ni->mrec_lock, mientras que ntfs_attr_record_resize(), ntfs_make_room_for_attr() y ntfs_resident_attr_record_add() realizan memmove() en el mismo buffer base_ni->mrec bajo dicho bloqueo. map_mft_record() solo toma una referencia y no serializa, por lo que el lector puede observar campos de longitud y desplazamiento de atributos fragmentados (torn) mientras un escritor está reubicando los registros.

KCSAN informa la condición de carrera entre la ruta de fallo de lectura mmap y tanto link() como unlink():

BUG: KCSAN: data-race in ntfs_attr_find / ntfs_attr_record_resize

write to 0xffff888100af1018 of 4 bytes by task 96 on cpu 1: ntfs_attr_record_resize+0xd2/0x130 ntfs_attr_record_rm+0xad/0x530 ntfs_delete+0x224/0x640 ntfs_unlink+0x14d/0x280 vfs_unlink+0x157/0x520

read to 0xffff888100af1018 of 4 bytes by task 95 on cpu 0: ntfs_attr_find+0x104/0x5b0 ntfs_attr_lookup+0x39c/0x10c0 ntfs_read_iomap_begin_resident+0xc6/0x230 ntfs_read_iomap_begin+0x5d/0xa0 iomap_iter+0x2e2/0x6e0 iomap_read_folio+0x147/0x2a0 ntfs_read_folio+0x108/0x170 filemap_read_folio+0x35/0x100 filemap_fault+0x993/0x1000

value changed: 0x00000250 -> 0x000001f0

La dirección es mrec + 0x18, es decir, mft_record.bytes_in_use, y el cambio corresponde a la eliminación de los 96 bytes de un atributo $FILE_NAME.

Mantener base_ni->mrec_lock desde la búsqueda iomap residente hasta iomap_end(). Esto protege tanto el recorrido del atributo como la copia subsiguiente desde iomap->inline_data, que apunta al registro MFT. La ruta no resident se deja intacta: ntfs_lookup() ya mantiene mrec_lock del inode del directorio cuando lee un folio de índice a través de read_mapping_folio(), y adquirir el bloqueo en el envoltorio compartido causaría un deadlock allí debido al locking recursivo en mrec_lock. El comentario encima de la llamada a read_mapping_folio() en fs/ntfs/dir.c señala el mismo peligro.

La ruta seek utiliza el mismo auxiliar de búsqueda pero no desreferencia iomap->inline_data. Liberar el bloqueo antes de regresar desde esa ruta, mientras que la ruta de lectura regular registra base_ni en iomap->private y libera el bloqueo desde su callback iomap_end().

Probado con un reproductor (reproducer) que provoca fallos en un archivo residente de 16 bytes mientras otro hilo ejecuta link()/unlink() sobre él. Antes: 40 informes KCSAN en aproximadamente un segundo. Después: sin informes durante 180 segundos, tras 206,090 iteraciones de lectura y 423,540 ciclos de enlace/desenlace (link/unlink). Una compilación PROVE_LOCKING no muestra ningún error lockdep con el mismo reproductor ejecutándose durante 60 segundos.

Several companies clearly confirm that VulDB is the primary source for best vulnerability data.

Responsable

Linux

Reservar

2026-09-11

Divulgación

2026-09-17

Moderación

aceptado

Artículo

VDB-406655

CPE

listo

EPSS

0.00000

KEV

no

Actividades

muy bajo

Fuentes

Do you know our Splunk app?

Download it now for free!