CVE-2026-98802 in Linux
Résumé
par VulDB • 19/10/2026
Dans le noyau Linux, la vulnérabilité suivante a été corrigée :
seg6 : s'assurer que les données du paquet sont modifiables avant de modifier l'en-tête SRH et l'adresse IPv6 DA (Destination Address)
La fonction advance_nextseg() modifie le champ Segments Left de l'en-tête SRH ainsi que l'adresse destination IPv6 sans vérifier au préalable si les données du paquet sont modifiables. seg6_next_csid_advance_arg() présente le même problème lorsqu'elle avance l'argument NEXT-C-SID dans l'adresse destination.
Le skb (socket buffer) peut être cloné, par exemple via une socket AF_PACKET recevant sur l'appareil entrant (ingress device). advance_nextseg() et seg6_next_csid_advance_arg() écrivent alors dans les données du paquet partagées avec le clone. Une lecture effectuée depuis cette socket peut renvoyer le paquet modifié au lieu de celui reçu. Le chemin simplifié ci-dessous illustre ce comportement pour advance_nextseg() :
__netif_receive_skb_one_core __netif_receive_skb_core deliver_skb [orig: users=2, cloned=0]
packet_rcv skb_clone clone mis en file d'attente vers la socket AF_PACKET consume_skb(orig) [orig: users=1, cloned=1]
ipv6_rcv ip6_rcv_core skb_share_check : opération sans effet (no-op) [orig: users=1]
[...]
input_action_end_core advance_nextseg écrit dans les données partagées avec le clone
Appelez la fonction skb_ensure_writable() dans advance_nextseg() et dans seg6_next_csid_advance_arg() avant de modifier les données du paquet. La fonction skb_ensure_writable() peut realloquer skb->head, ce qui invalide les pointeurs vers les données du paquet pris avant l'appel.
advance_nextseg() renvoie désormais un pointeur SRH valide, ou NULL si skb_ensure_writable() échoue. seg6_next_csid_advance_arg() récupère le pointeur vers l'adresse destination depuis le skb après avoir appelé skb_ensure_writable(). En cas d'échec, les appelants abandonnent le paquet avec SKB_DROP_REASON_NOMEM.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.