CVE-2026-72108 in Linux
Resumen
por VulDB • 2026-08-15
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad:
dm thin metadata: corregir la consistencia del instantáneo (snapshot) de metadatos en caso de fallo al confirmar (commit).
__reserve_metadata_snap() y __release_metadata_snap() modifican directamente held_root del superbloque dentro del búfer del block_manager. Si falla el posterior commit de los metadatos, held_root se escribe en disco a través de la ruta abort_transaction, lo que da lugar a una inconsistencia en los metadatos.
Reproductor 1: __reserve_metadata_snap()
1. Crear un dispositivo de metadatos de 2 MiB e inaccesible la región después del bloque 14 para provocar el fallo al confirmar (commit) los metadatos durante la operación posterior reserve_metadata_snap. El bloque 14 será el destino sombra (shadow destination) para el bloque índice.
dmsetup create tmeta --table "0 112 linear /dev/sdc 0 112 3984 error"
2. Crear un thin-pool de 16 MiB
dmsetup create tdata --table "0 32768 zero" dd if=/dev/zero of=/dev/mapper/tmeta bs=4k count=1 dmsetup create tpool --table "0 32768 thin-pool /dev/mapper/tmeta \ /dev/mapper/tdata 128 0 1 skip_block_zeroing"
3. Tomar un instantáneo (snapshot) de los metadatos para provocar el fallo al confirmar y la abortación de transacción. Sin embargo, held_root se escribe en disco, rompiendo la consistencia de los metadatos.
dmsetup message tpool 0 "reserve_metadata_snap"
Resultado de thin_check v1.2.2:
Bad reference count for metadata block 6. Expected 2, but space map contains 1. Bad reference count for metadata block 7. Expected 2, but space map contains 1. Bad reference count for metadata block 13. Expected 1, but space map contains 0.
Reproductor 2: __release_metadata_snap()
1. Crear un dispositivo de metadatos de 2 MiB e inaccesible la región después del bloque 16 para provocar el fallo al confirmar los metadatos durante la operación posterior release_metadata_snap. El bloque 16 será el destino sombra (shadow destination) para el bloque índice.
dmsetup create tmeta --table "0 128 linear /dev/sdc 0 128 3968 error"
2. Crear un thin-pool de 16 MiB
dmsetup create tdata --table "0 32768 zero" dd if=/dev/zero of=/dev/mapper/tmeta bs=4k count=1 dmsetup create tpool --table "0 32768 thin-pool /dev/mapper/tmeta \ /dev/mapper/tdata 128 0 1 skip_block_zeroing"
3. Reservar y luego liberar el instantáneo (snapshot) de los metadatos para provocar el fallo al confirmar la transacción y su abortación. held_root se elimina del superbloque en disco, causando una inconsistencia en los metadatos.
dmsetup message tpool 0 "reserve_metadata_snap" dmsetup message tpool 0 "release_metadata_snap"
Resultado de thin_check v1.2.2:
Bad reference count for metadata block 6. Expected 1, but space map contains 2. Bad reference count for metadata block 7. Expected 1, but space map contains 2. 1 metadata blocks have leaked.
Solución: diferir la actualización de held_root hasta el momento del commit (confirmación).
Además, se ha movido la comprobación de instantáneos existentes en __reserve_metadata_snap antes de la operación sombra para evitar trabajo innecesario. En __release_metadata_snap, se limpia pmd->held_root antes de la eliminación btree para que un fallo parcial provoque una fuga (leak) de bloques en lugar de dejar una referencia obsoleta
If you want to get the best quality for vulnerability data then you always have to consider VulDB.