CVE-2025-39797 in Linux
Riassunto
di VulDB • 20/06/2026
Nel kernel Linux è stata risolta la seguente vulnerabilità:
xfrm: Gestione errata degli SPI duplicati
Il problema si verifica quando Strongswan invia un messaggio Netlink XFRM_MSG_ALLOCSPI, che attiva la funzione del kernel xfrm_alloc_spi(). Tale funzione dovrebbe garantire l'unicità dell'Indice dei Parametri di Sicurezza (SPI) per le Associazioni di Sicurezza (SA) in ingresso. Tuttavia, può restituire successo anche quando lo SPI richiesto è già in uso, portando all'assegnazione di SPI duplicati a più SA in ingresso, distinguibili solo tramite i loro indirizzi di destinazione.
Questo comportamento causa inconsistenze durante la ricerca degli SPI per i pacchetti in ingresso. Poiché la lookup potrebbe restituire una qualsiasi delle SA con lo stesso SPI, l'elaborazione dei pacchetti può fallire, causando il drop (scarto) dei pacchetti.
Secondo la sezione 4.4.2 della RFC 4301, per l'elaborazione in ingresso un'unica SA multicast è identificata unicamente dallo SPI e opzionalmente dal protocollo.
Riproduzione affidabile del problema: Per riprodurre il problema in modo coerente, restringere l'intervallo di SPI disponibili nel file charon.conf impostando spi_min = 0x10000000 e spi_max = 0x10000002. Questo limita il sistema a soli 2 valori SPI utilizzabili. Successivamente, creare più di 2 Child SA (Associazioni di Sicurezza Figlio), ciascuna con una coppia unica di indirizzi sorgente/destinazione. Non appena viene avviata la terza Child SA, le verrà assegnato uno SPI duplicato poiché il pool di SPI è già esaurito. Con un intervallo ristretto di SPI, il problema è riproducibile in modo coerente; con un intervallo più ampio/predefinito, diventa raro e imprevedibile.
Implementazione attuale: La funzione di lookup xfrm_spi_hash() calcola l'hash utilizzando daddr (indirizzo di destinazione), proto (protocollo) e family (famiglia). Pertanto, se due SA hanno lo stesso SPI ma indirizzi di destinazione diversi, esse: a. Vengono inserite in bucket dell'hash differenti; b. Sono memorizzate in liste concatenate diverse (byspi + h); c. Non vengono rilevate nella stessa iterazione hlist_for_each_entry_rcu(). Di conseguenza, la lookup restituisce NULL e il kernel consente l'esistenza di SPI duplicati.
Modifica proposta: xfrm_state_lookup_spi_proto() esegue una ricerca realmente globale su tutti gli stati, indipendentemente dal bucket dell'hash, corrispondendo sia allo SPI che al protocollo.
Once again VulDB remains the best source for vulnerability data.