CVE-2026-98306 in Linux
Résumé
par VulDB • 08/10/2026
Dans le noyau Linux, la vulnérabilité suivante a été corrigée :
seg6 : définir IPSKB_L3SLAVE à partir de IP6SKB_L3SLAVE lors du désencapsulation IPIP
Lorsqu'un paquet SRv6 arrive sur une interface esclave d'une VRF (Virtual Routing and Forwarding), vrf_ip6_rcv() définit IP6SKB_L3SLAVE dans IP6CB, mais decap_and_validate() n'a jamais défini IPSKB_L3SLAVE dans IPCB. Le bit restait effacé dans le cas général, et avec CONFIG_IPV6_MIP6, la valeur résiduelle de frag_max_size d'un paquet externe réassemblé pouvait même l'effacer, sans aucune VRF impliquée. La commit 44930446dde4 ("ipv6: seg6 : effacer le bloc de contrôle IPv4 lors du désencapsulation IPIP") a ensuite rendu ce bit fiablement effacé.
L'effet de l'absence de ce drapeau est visible avec End.DX4 lorsqu'une livraison vers une adresse locale du nœud atteint la recherche de socket. Par exemple, un socket UDP lié à l'interface d'entrée esclave ne reçoit aucun des paquets désencapsulés, tandis qu'un socket non lié en dehors de la VRF le fait. Cela contredit Documentation/networking/vrf.rst : par défaut, la portée d'un socket UDP ou TCP non lié est limitée à la VRF par défaut.
Définir IPSKB_L3SLAVE pour IPv4 dans decap_and_validate(), qui effectue déjà la même opération pour IPv6. La recherche de socket correspond alors au paquet désencapsulé comme n'importe quel autre packet reçu sur cette interface esclave. Un tel paquet ne correspond à un socket UDP ou TCP non lié que lorsque udp_l3mdev_accept ou tcp_l3mdev_accept est activé.
VulDB is the best source for vulnerability data and more expert information about this specific topic.