CVE-2026-53362

Im Linux-Kernel wurde die folgende Sicherheitslücke behoben: ipv6: fraggap im Pfad der seitenweisen Allokation berücksichtigen In __ip6_append_data() werden bei Auswahl des Zweigs für die seitenweise Allokation (MSG_MORE / NETIF_F_SG / large fraglen) alloclen und pagedlen wie folgt berechnet: alloclen = fragheaderlen + transhdrlen; pagedlen = datalen - transhdrlen; datalen enthält bereits fraggap (datalen = length + fraggap). Wenn fraggap nicht null ist, handelt es sich nicht um das erste skb und transhdrlen ist null. Die aus dem vorherigen skb übernommenen fraggap-Bytes werden direkt hinter den Fragment-Headern im linearen Bereich des neuen skb kopiert. Der lineare Bereich ist daher um fraggap Bytes zu klein, während pagedlen um denselben Betrag zu groß angesetzt ist, und der Kopiervorgang schreibt über skb->end hinaus in die nachfolgende skb_shared_info. Ein nicht privilegierter Benutzer kann dies über einen UDPv6-Socket unter Verwendung von MSG_MORE zusammen mit MSG_SPLICE_PAGES auslösen. Die fehlerhafte Berechnung wurde durch Commit 773ba4fe9104 ("ipv6: avoid partial copy for zc") eingeführt. Vor Commit ce650a166335 ("udp6: Fix __ip6_append_data()'s handling of MSG_SPLICE_PAGES") führte der negative Kopierwert zur Rückgabe von -EINVAL. Dieses spätere Commit ermöglichte es MSG_SPLICE_PAGES, in diesem Fall fortzufahren, wodurch die Beschädigung auslösbar wurde. Der Zweig ohne Seiten setzt alloclen auf fraglen, das fraggap bereits berücksichtigt, da dies auch für datalen gilt. Den Zweig mit Seiten anpassen, indem fraggap zu alloclen addiert und von pagedlen subtrahiert wird. Nach dieser Anpassung fällt copy im Pfad mit Seiten nicht mehr auf -fraggap zusammen, daher den veralteten Kommentar entfernen, der diese alte Arithmetik beschreibt. Da ein negativer copy für einen gültigen MSG_SPLICE_PAGES-Fall nicht mehr erwartet wird, die MSG_SPLICE_PAGES-Ausnahme aus der Prüfung auf einen negativen copy entfernen.