CVE-2026-80906 in Linux
Résumé
par VulDB • 04/09/2026
Dans le noyau Linux, la vulnérabilité suivante a été corrigée :
net: packet : correction de l'erreur sur transport_header lors de l'envoi d'une trame balisée VLAN
Dans `packet_parse_headers()`, lors du traitement d'une trame balisée VLAN, `skb_set_network_header()` est appelé pour avancer network_header au-delà de la balise VLAN vers l'en-tête du protocole interne. Ensuite, `skb_probe_transport_header()` est appelée avec `skb->protocol` toujours défini sur le EtherType VLAN externe (par exemple ETH_P_8021Q), tandis que nhoff (dérivé de skb_network_offset()) pointe déjà au-delà de la balise VLAN vers l'en-tête du protocole interne.
Dans `__skb_flow_dissect()`, proto est initialisé à ETH_P_8021Q et nhoff pointe au-delà de la balise VLAN. Lorsque le dissecteur atteint le cas ETH_P_8021Q, il lit une structure vlan_hdr à l'offset nhoff via `__skb_header_pointer()`, mais cet offset contient l'en-tête du protocole interne (par exemple un en-tête IP). Les octets sont mal interprétés comme un en-tête VLAN, générant un EtherType encapsulé erroné qui ne correspond à aucun protocole connu. Le dissecteur renvoie false, donc `skb_probe_transport_header()` n'appelle jamais `skb_set_transport_header()`, laissant transport_header à sa valeur sentinelle non initialisée (~0U).
Déplacer l'appel de `skb_probe_transport_header()` avant celui de `skb_set_network_header()`. Au moment où `skb_probe_transport_header()` est appelé, network_header pointe toujours vers l'en-tête VLAN, donc nhoff pointe correctement vers l'en-tête VLAN. Le dissecteur de flux peut alors analyser l'en-tête VLAN, extraire le EtherType interne et avancer nhoff vers l'en-tête du protocole interne, permettant ainsi à transport_header d'être défini correctement.
If you want to get best quality of vulnerability data, you may have to visit VulDB.