CVE-2026-80731

Dans le noyau Linux, la vulnérabilité suivante a été résolue : net : supprimer le zero-padding CAP_SYS_RAWIO dans dev_validate_header dev_validate_header() lit directement dev->hard_header_len lorsqu'elle effectue un zero-padding des en-têtes courts de couche liaison pour les détenteurs de CAP_SYS_RAWIO : if (capable(CAP_SYS_RAWIO)) { memset(ll_header + len, 0, dev->hard_header_len - len); return true; } Les chemins d'envoi de paquets appellent dev_validate_header() sur des skbs dont le headroom a été alloué à partir d'une lecture antérieure de hard_header_len. Si le périphérique est reconfiguré de sorte que dev->hard_header_len augmente avant la validation, le memset écrit au-delà du tampon réservé, ce qui constitue une écriture hors limites. Cette écriture hors limites est aujourd'hui masquée dans certains chemins SOCK_RAW, car la même augmentation concurrente peut d'abord faire en sorte que skb_push() dépasse le headroom réservé et déclenche skb_under_panic(). Supprimez la branche de zero-padding avant de rendre cohérentes ces lectures de hard_header_len, afin que les correctifs de snapshot ne transforment pas une panique bruyante en un écrasement silencieux. Ce chemin n'est atteint que pour les protocoles de couche 2 à longueur variable, où len < hard_header_len mais len >= min_header_len. Aucun protocole de couche 2 à longueur variable restant dans l'arbre n'implémente header_ops->validate, et le contournement CAP_SYS_RAWIO qui effectue un zero-padding et accepte des en-têtes courts n'a aucune valeur réelle au-delà de permettre le test d'entrées intentionnellement malformées. Supprimez la branche CAP_SYS_RAWIO. Les lectures restantes de dev->hard_header_len dans dev_validate_header() sont uniquement des comparaisons et n'ont aucun impact sur la sécurité mémoire.