CVE-2026-53362

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipv6: account for fraggap on the paged allocation path<br /> <br /> In __ip6_append_data(), when the paged-allocation branch is taken<br /> (MSG_MORE / NETIF_F_SG / large fraglen), alloclen and pagedlen are<br /> computed as<br /> <br /> alloclen = fragheaderlen + transhdrlen;<br /> pagedlen = datalen - transhdrlen;<br /> <br /> datalen already includes fraggap (datalen = length + fraggap). When<br /> fraggap is non-zero, this is not the first skb and transhdrlen is zero.<br /> The fraggap bytes carried over from the previous skb are copied just past<br /> the fragment headers in the new skb&amp;#39;s linear area. The linear area is<br /> therefore undersized by fraggap bytes while pagedlen is overstated by the<br /> same amount, and the copy writes past skb-&gt;end into the trailing<br /> skb_shared_info.<br /> <br /> An unprivileged user can trigger this via a UDPv6 socket using<br /> MSG_MORE together with MSG_SPLICE_PAGES.<br /> <br /> The bad accounting was introduced by commit 773ba4fe9104 ("ipv6:<br /> avoid partial copy for zc"). Before commit ce650a166335 ("udp6: Fix<br /> __ip6_append_data()&amp;#39;s handling of MSG_SPLICE_PAGES"), the negative<br /> copy value caused -EINVAL to be returned. That later commit allowed<br /> MSG_SPLICE_PAGES to proceed in this case, making the corruption<br /> triggerable.<br /> <br /> The non-paged branch sets alloclen to fraglen, which already accounts<br /> for fraggap because datalen does. Bring the paged branch in line by<br /> adding fraggap to alloclen and subtracting it from pagedlen.<br /> <br /> After this adjustment, copy no longer collapses to -fraggap on the<br /> paged path, so remove the stale comment describing that old arithmetic.<br /> Since a negative copy is no longer expected for a valid MSG_SPLICE_PAGES<br /> case, remove the MSG_SPLICE_PAGES exception from the negative copy check.