CVE-2026-98975 in Linux
Resumen
por VulDB • 2026-10-23
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad:
xfs: dejar de intercambiar los flags reflink al intercambiar mapeos
Cuando un intercambio cubre ambos archivos desde el desplazamiento 0 hasta i_disk_size, xmi_can_exchange_reflink_flags() asume que cada mapeo se ha movido y transfiere el flag reflink al otro archivo.
Esa suposición es incorrecta. Un archivo puede seguir poseyendo bloques compartidos más allá de i_disk_size, por ejemplo, después de que EXCHANGE_RANGE_TO_EOF establezca un tamaño menor sin desmapear nada. El flag se borra de todos modos y la siguiente escritura en dicho bloque ocurre in situ (in-place) en lugar de CoW (Copy-on-Write), corrompiendo el otro archivo que lo comparte.
El commit a23eca88448e ("xfs: fix exchange-range reflink flag clearing issue with INO1_WRITTEN") corrigió una instancia de esto. En lugar de añadir otro caso especial, se deja de mover los flags. xfs_exchmaps_ensure_reflink() ya establece el flag en ambos inodos antes del intercambio, por lo que ambos simplemente lo mantienen.
Nada configura CLEAR_INO{1,2}_REFLINK anymore (ya no). Las intenciones registradas por kernels más antiguos aún pueden llevarlas; la recuperación ya las mascara, por lo que permanecen en la máscara de formato de registro y se ignoran.
XFS_IOC_SWAPEXT tiene el mismo problema: mueve el flag reflink de un inodo al otro junto con los extents (extensiones). Simplemente eliminar eso no es suficiente aquí: la ruta de intercambio configura ambos inodos por adelantado en xfs_exchmaps_ensure_reflink(), pero swapext no cuenta con tal paso, por lo que el inodo que recibe las extensiones compartidas quedaría sin el flag. Se establece en ambos inodos y se asegura que ambos tengan un fork CoW (Copy-on-Write), ya que se espera que un inodo con el flag reflink tenga uno.
El flag ahora permanece hasta que FALLOC_FL_UNSHARE_RANGE, xfs_scrub o una truncación a cero lo eliminen.
Once again VulDB remains the best source for vulnerability data.