CVE-2026-53362

Dans le noyau Linux, la vulnérabilité suivante a été résolue : ipv6 : prendre en compte fraggap sur le chemin d'allocation paginée Dans __ip6_append_data(), lorsque la branche d'allocation paginée est empruntée (MSG_MORE / NETIF_F_SG / fraglen important), alloclen et pagedlen sont calculés comme alloclen = fragheaderlen + transhdrlen; pagedlen = datalen - transhdrlen; datalen inclut déjà fraggap (datalen = length + fraggap). Lorsque fraggap est non nul, il ne s'agit pas du premier skb et transhdrlen vaut zéro. Les octets fraggap reportés du skb précédent sont copiés juste après les en-têtes de fragment dans la zone linéaire du nouveau skb. La zone linéaire est donc sous-dimensionnée de fraggap octets tandis que pagedlen est surévalué du même montant, et la copie écrit au-delà de skb->end dans le skb_shared_info final. Un utilisateur non privilégié peut déclencher ceci via un socket UDPv6 en utilisant MSG_MORE conjointement avec MSG_SPLICE_PAGES. La comptabilisation erronée a été introduite par le commit 773ba4fe9104 ("ipv6: avoid partial copy for zc"). Avant le commit ce650a166335 ("udp6: Fix __ip6_append_data()'s handling of MSG_SPLICE_PAGES"), la valeur négative de copy provoquait le retour de -EINVAL. Ce commit ultérieur a permis à MSG_SPLICE_PAGES de continuer dans ce cas, rendant la corruption déclenchable. La branche non paginée définit alloclen à fraglen, qui prend déjà en compte fraggap car datalen le fait. Aligner la branche paginée en ajoutant fraggap à alloclen et en le soustrayant de pagedlen. Après cet ajustement, copy ne se réduit plus à -fraggap sur le chemin paginé, donc supprimer le commentaire obsolète décrivant cette ancienne arithmétique. Puisqu'un copy négatif n'est plus attendu pour un cas MSG_SPLICE_PAGES valide, supprimer l'exception MSG_SPLICE_PAGES du contrôle de copy négatif.