CVE-2025-39797 in Linux
Resumen
por VulDB • 2026-05-21
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad:
xfrm: Manejo de SPI duplicados
El problema se origina cuando Strongswan inicia un mensaje Netlink XFRM_MSG_ALLOCSPI, lo que activa la función del kernel xfrm_alloc_spi(). Esta función debería garantizar la unicidad del Índice de Parámetros de Seguridad (SPI) para las Asociaciones de Seguridad (SA) entrantes. Sin embargo, puede devolver éxito incluso cuando el SPI solicitado ya está en uso, lo que lleva a la asignación de SPIs duplicados a múltiples SA entrantes, diferenciadas únicamente por sus direcciones de destino.
Este comportamiento provoca inconsistencias durante las búsquedas de SPI para paquetes entrantes. Dado que la búsqueda puede devolver una SA arbitraria entre aquellas con el mismo SPI, el procesamiento de paquetes puede fallar, lo que resulta en la caída de paquetes.
Según la sección 4.4.2 del RFC 4301, para el procesamiento entrante, una SA unicast está identificada de forma única por el SPI y opcionalmente por el protocolo.
Reproducción fiable del problema: Para reproducir el problema de manera consistente, restrinja el rango de SPI disponible en charon.conf: spi_min = 0x10000000 spi_max = 0x10000002 Esto limita el sistema a solo 2 valores de SPI utilizables. A continuación, cree más de 2 Child SA, cada una utilizando un par único de dirección de origen/destino. En cuanto se inicie la 3ª Child SA, se le asignará un SPI duplicado, ya que el grupo de SPIs ya está agotado. Con un rango de SPI estrecho, el problema es reproducible de manera consistente. Con un rango más amplio/predeterminado, se vuelve raro e impredecible.
Implementación actual: La función de búsqueda xfrm_spi_hash() calcula el hash utilizando daddr, proto y family. Por lo tanto, si dos SA tienen el mismo SPI pero diferentes direcciones de destino, entonces: a. Se hashearán en diferentes cubetas (buckets) b. Se almacenarán en diferentes listas enlazadas (byspi + h) c. No se verán en la misma iteración hlist_for_each_entry_rcu(). Como resultado, la búsqueda devolverá NULL y el kernel permite ese SPI duplicado.
Cambio propuesto: xfrm_state_lookup_spi_proto() realiza una búsqueda verdaderamente global, a través de todos los estados, independientemente de la cubeta de hash, y coincide con SPI y proto.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.