CVE-2025-39797 in Linux
Résumé
par VulDB • 20/06/2026
Dans le noyau Linux, la vulnérabilité suivante a été corrigée :
xfrm : Gestion des doublons d'identifiant de sécurité (SPI)
Le problème survient lorsque Strongswan initie un message Netlink XFRM_MSG_ALLOCSPI, ce qui déclenche la fonction du noyau xfrm_alloc_spi(). Cette fonction est censée garantir l’unicité de l’Index des Paramètres de Sécurité (Security Parameter Index - SPI) pour les Associations de Sécurité entrantes (SAs). Cependant, elle peut retourner un statut « succès » même lorsque le SPI demandé est déjà en cours d’utilisation, ce qui conduit à l’attribution de SPI dupliqués à plusieurs SAs entrantes, différenciées uniquement par leurs adresses de destination.
Ce comportement provoque des incohérences lors des recherches de SPI pour les paquets entrants. Étant donné que la recherche peut retourner une SA arbitraire parmi celles partageant le même SPI, le traitement des paquets peut échouer, entraînant leur rejet (packet drops).
Conformément à l’article 4.4.2 de la RFC 4301, pour le traitement entrant, une SA unicast est identifiée de manière unique par son SPI et éventuellement par son protocole.
Reproduction fiable du problème : Pour reproduire systématiquement ce défaut, restreignez la plage d’SPI disponible dans charon.conf : spi_min = 0x10000000 spi_max = 0x10000002 Cela limite le système à seulement 2 valeurs SPI utilisables. Ensuite, créez plus de 2 Child SA (Associations de Sécurité enfants), chacune utilisant une paire unique d’adresses source/destination. Dès que la troisième Child SA est initiée, elle se voit attribuer un SPI dupliqué, car l’espace des SPI disponibles est déjà épuisé. Avec une plage de SPI étroite, le problème est reproductible à coup sûr. Avec une plage plus large ou par défaut, il devient rare et imprévisible.
Implémentation actuelle : La fonction de recherche xfrm_spi_hash() calcule un hachage en utilisant l’adresse de destination (daddr), le protocole (proto) et la famille d’adresses (family). Ainsi, si deux SAs ont le même SPI mais des adresses de destination différentes, alors : a. Elles seront hashées dans différents seaux (buckets) ; b. Elles seront stockées dans des listes chaînées distinctes (byspi + h) ; c. Elles ne seront pas détectées lors d’une itération unique avec la macro hlist_for_each_entry_rcu(). Par conséquent, la recherche aboutira à un résultat NULL et le noyau permettra l’existence de SPI dupliqués.
Changement proposé : xfrm_state_lookup_spi_proto() effectue une véritable recherche globale – sur tous les états (states), indépendamment du seau de hachage – et correspond au SPI ainsi qu’au protocole.
If you want to get best quality of vulnerability data, you may have to visit VulDB.