UBUNTU-CVE-2026-99191: Medium severity ubuntu/linux-hwe-edge vulnerability
In the Linux kernel, the following vulnerability has been resolved: calipso: keep BIG TCP payloadlen in calipsoskbuffsetattr() calipsoskbuffsetattr() adjusts payloadlen by the length of the option it inserts or resizes: payload = ntohs(ip6hdr->payloadlen); ip6hdr->payloadlen = htons(payload + lendelta); GRO can build BIG TCP packets larger than IPV6MAXPLEN, and stores payloadlen == 0 for them; ipv6payloadlen() then falls back to skb->len. For such a packet forwarded to a destination mapped to CALIPSO, the code above writes lendelta (or 65536 + lendelta when shrinking) into payloadlen, and ipv6payloadlen() no longer falls back to skb->len. nftables, conntrack and schcake rely on it. The same arithmetic also wraps when a packet grows past IPV6MAXPLEN, and a BIG TCP packet that shrinks below IPV6MAXPLEN should get its real length back. Set payloadlen from the skb length with ipv6setpayloadlen(), which stores 0 above IPV6MAXPLEN and the real length otherwise, as ipv6grocomplete() does. The network header was just reset to skb->data, so skb->len - sizeof(ip6hdr) is the payload length. Tested on one kernel (arm64, QEMU) with SELinux permissive, a minimal mdp-generated policy (networkpeercontrols=1), "netlabelctl calipso add pass doi:16" and a NetLabel mapping of fd00:2::/64 to CALIPSO DOI 16. calipsoskbuffsetattr() was called through netlblskbuffsetattr() from a test-only debugfs hook (not part of this patch) adding a level-only label; payloadlen after the call: case before fix after fix real length 1000, unlabeled 1016 1016 1016 70000 GSO, payloadlen 0 16 0 70016 65530 GSO, grows past MAXPLEN 10 0 65546 65540 GSO with a 24 byte hop header, shrinks below MAXPLEN 65528 65532 65532 1000 with a 24 byte hop header 992 992 992 (0 means ipv6payloadlen() returns the real length.) On the forward path, with a client injecting unlabeled UDP through a router to a server, the router adds the CALIPSO option and the server delivers all datagrams (Udp6InDatagrams 5, Ip6InTruncatedPkts 0) with this patch.
Affected Software
Event History
Frequently Asked Questions
Which systems are most likely to be exposed to this issue?
Systems using an affected Ubuntu Linux kernel are relevant when they process IPv6 BIG TCP traffic and forward packets to a destination mapped to CALIPSO. The issue involves packets whose IPv6 payload exceeds IPV6_MAXPLEN, including cases where packet size changes during CALIPSO option insertion or resizing.
What conditions are needed to trigger the incorrect payload length handling?
A BIG TCP packet must have an IPv6 payload larger than IPV6_MAXPLEN, for which the IPv6 payload_len field is stored as zero, and it must be processed by calipso_skbuff_setattr(). The faulty handling can occur when the CALIPSO option causes the packet to grow or shrink.
What is the practical impact of the malformed payload length?
The IPv6 payload length can be set incorrectly rather than remaining zero for oversized packets or being restored to the real value after shrinking. Components including nf_tables, conntrack, and sch_cake rely on this length value.
How can administrators determine whether their environment is potentially affected?
Review whether the system runs one of the listed Ubuntu kernel packages and handles IPv6 BIG TCP traffic with CALIPSO-mapped destinations. Environments that do not use this traffic path are not described as reaching the vulnerable code path.