PT-2026-55700 · Linux · Linux
Published
2026-07-04
·
Updated
2026-07-04
·
CVE-2026-53362
None
No severity ratings or metrics are available. When they are, we'll update the corresponding info on the page.
In the Linux kernel, the following vulnerability has been resolved:
ipv6: account for fraggap on the paged allocation path
In ip6 append data(), when the paged-allocation branch is taken
(MSG MORE / NETIF F SG / large fraglen), alloclen and pagedlen are
computed as
alloclen = fragheaderlen + transhdrlen;
pagedlen = datalen - transhdrlen;datalen already includes fraggap (datalen = length + fraggap). When
fraggap is non-zero, this is not the first skb and transhdrlen is zero.
The fraggap bytes carried over from the previous skb are copied just past
the fragment headers in the new skb's linear area. The linear area is
therefore undersized by fraggap bytes while pagedlen is overstated by the
same amount, and the copy writes past skb->end into the trailing
skb shared info.
An unprivileged user can trigger this via a UDPv6 socket using
MSG MORE together with MSG SPLICE PAGES.
The bad accounting was introduced by commit 773ba4fe9104 ("ipv6:
avoid partial copy for zc"). Before commit ce650a166335 ("udp6: Fix
ip6 append data()'s handling of MSG SPLICE PAGES"), the negative
copy value caused -EINVAL to be returned. That later commit allowed
MSG SPLICE PAGES to proceed in this case, making the corruption
triggerable.
The non-paged branch sets alloclen to fraglen, which already accounts
for fraggap because datalen does. Bring the paged branch in line by
adding fraggap to alloclen and subtracting it from pagedlen.
After this adjustment, copy no longer collapses to -fraggap on the
paged path, so remove the stale comment describing that old arithmetic.
Since a negative copy is no longer expected for a valid MSG SPLICE PAGES
case, remove the MSG SPLICE PAGES exception from the negative copy check.
Found an issue in the description? Have something to add? Feel free to write us 👾
Related Identifiers
Affected Products
Linux