CVE-2025-39797 in Linux
Sumário
de VulDB • 19/06/2026
No kernel do Linux, a seguinte vulnerabilidade foi resolvida:
xfrm: Tratamento duplicado de SPI (Security Parameter Index)
O problema origina-se quando o Strongswan inicia uma mensagem Netlink XFRM_MSG_ALLOCSPI, que aciona a função do kernel xfrm_alloc_spi(). Esta função deveria garantir a unicidade do Índice de Parâmetros de Segurança (SPI) para as Associações de Segurança (SAs) de entrada. No entanto, ela pode retornar sucesso mesmo quando o SPI solicitado já está em uso, levando à atribuição de SPIs duplicados a múltiplas SAs de entrada, diferenciadas apenas pelos seus endereços de destino.
Este comportamento causa inconsistências durante as consultas de SPI para pacotes de entrada. Como a consulta pode retornar uma SA arbitrária entre aquelas com o mesmo SPI, o processamento do pacote pode falhar, resultando na perda (drop) dos pacotes.
De acordo com a seção 4.4.2 da RFC 4301, no processamento de entrada, uma SA unicast é identificada unicamente pelo SPI e opcionalmente pelo protocolo.
Reproduzindo o problema de forma confiável: Para reproduzir consistentemente o problema, restrinja o intervalo disponível de SPIs em charon.conf : spi_min = 0x10000000 spi_max = 0x10000002 Isso limita o sistema a apenas 2 valores utilizáveis de SPI. Em seguida, crie mais de 2 Child SAs (Associações de Segurança Filhas), cada uma usando um par único de endereço src/dst. Assim que a 3ª Child SA for iniciada, ela receberá um SPI duplicado, já que o pool de SPIs estará esgotado. Com um intervalo estreito de SPIs, o problema é reproduzível consistentemente. Com um intervalo mais amplo/padrão, torna-se raro e imprevisível.
Implementação atual: A função de consulta xfrm_spi_hash() calcula o hash usando daddr (endereço de destino), proto (protocolo) e family (família). Portanto, se duas SAs tiverem o mesmo SPI mas endereços de destino diferentes, elas: a. Serão distribuídas em buckets diferentes do hash; b. Serão armazenadas em listas encadeadas distintas (byspi + h); c. Não serão vistas na mesma iteração hlist_for_each_entry_rcu(). Como resultado, a consulta retornará NULL e o kernel permitirá que ocorra um SPI duplicado.
Alteração proposta: xfrm_state_lookup_spi_proto() realiza uma busca verdadeiramente global - em todos os estados, independentemente do bucket de hash - e corresponde ao SPI e ao protocolo.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.