CVE-2025-21629 - How a Linux Kernel Networking Bug Broke—and Fixed—TCP Offload for Big IPv6 Packets

In early 2025, Linux kernel networking experts encountered—and patched—CVE-2025-21629, a subtle bug around IPv6 checksum offload and “BIG TCP.” This issue temporarily broke hardware acceleration for large IPv6 packets on some network cards, causing confusing kernel warnings and potential network slowdowns. Here’s an in-depth but simple breakdown: what went wrong, what it means, sample logs, and how it was fixed.

What Is CVE-2025-21629?

CVE-2025-21629 affects the Linux kernel's implementation of hardware checksum offload for certain IPv6 packets—specifically, *BIG TCP* packets with IPv6 extension headers (like jumbo frames).

Hardware checksum offloading lets network cards automatically calculate packet checksums. This saves CPU work when sending lots of traffic—important for servers and data-centers.

In this case, a previous kernel change (the “blamed commit”) overly restricted hardware offload for IPv6 packets that had extra (extension) headers, even when it was safe for big TCP packets. This triggered kernel warnings and turned off hardware acceleration, impacting network performance.

Driver Flags:

Most network interfaces advertising NETIF_F_IPV6_CSUM only want to offload checksum for “plain vanilla” IPv6 packets:

IPv6|UDP

If the packet has any IPv6 *extension headers* (often used for IPv6’s advanced features like routing, jumbograms, security), hardware offload was disabled for safety.

BIG TCP and Jumbo Extension:

Newer Linux kernels support very large (“jumbo”) TCP packets for better performance. These packets legally use an IPv6 extension header: IPV6_TLV_JUMBO. It essentially says, "Hey, this is a jumbo packet!"

Who Actually Sees the Extension Header?

In BIG TCP, the IPV6_TLV_JUMBO extension header is only used internally (for taps like tcpdump), not when the packet is sent down the wire. But the kernel code, seeing any extension header, blocked the hardware offload.

`text

WARNING: CPU: 13 PID: 23472 at net/core/dev.c:3129 skb_warn_bad_offload+xc4/xe

And offload was disallowed, reducing performance.

---

What Did the Patch Change?

Developers realized that the old check was *too strict*. The extension header is safe for offload in the very case of BIG TCP with jumbo packets—since those headers are never really sent on the wire by offloading hardware.

The patch

- Relaxes the check for IPv6 extension headers if (and only if) the packet’s only extension is IPV6_TLV_JUMBO before TCP/UDP, i.e., for BIG TCP.

Key code insight

// Before the patch: no offload if any IPv6 extension header
if (skb->ip_summed == CHECKSUM_PARTIAL &&
    skb->protocol == htons(ETH_P_IPV6) &&
    skb_checksum_start_offset(skb) != sizeof(struct ipv6hdr))
    skb_warn_bad_offload();

// After the patch: minor exception for jumbograms
if (skb->ip_summed == CHECKSUM_PARTIAL &&
    skb->protocol == htons(ETH_P_IPV6) &&
    !ipv6_has_hopopt_jumbo(skb))
    skb_warn_bad_offload();

Where

- ipv6_has_hopopt_jumbo(skb) returns true if the only extension header is the jumbogram header and it's safe for offloading.

Exploitation Details

This flaw didn't open the kernel to remote exploits, but it WAS very impactful in server/datacenter environments handling BIG TCP. Here's what sysadmins and attackers might've seen or done:

No privilege escalation:

This bug is a *denial-of-service* to hardware offload, not a direct vector for code execution or privilege escalation.

How to trigger:

Configure BIG TCP with IPV6 jumbo frames and capture traffic—watch the kernel log fill up with warnings.

from scapy.all import *

pkt = IPv6(dst="your-server")/IPv6ExtHdrHopByHop(options=Jumbo(jumboplen=9001))/TCP(dport=80)

References and Further Reading

- Original Linux kernel patch discussion
- Linux kernel netdev list on BIG TCP
- NETIF_F_IPV6_CSUM documentation
- What is IPv6 Jumbogram? - RFC 2675
- Patch merged in mainline

Conclusion

CVE-2025-21629 was a kernel-level snag with a simple root cause: misunderstood extension headers in IPv6 BIG TCP offload. This only affected a niche (but important) use case—BIG TCP jumbograms with enabled hardware TCP segmentation—but its performance impact in those environments was huge. If you run modern Linux boxes with large IPv6 traffic, upgrading to a kernel with this fix is crucial.

If you want to dive deeper or troubleshoot, check the links above. Always check your dmesg for offload warnings—and remember, not every kernel bug is a dramatic security threat, but little things can disrupt big datacenter performance!


*Written exclusively for you by a Linux kernel observer. For feedback or questions, reach out on your favorite sysadmin forum!*

Timeline

Published on: 01/15/2025 13:15:15 UTC
Last modified on: 05/04/2025 13:05:58 UTC