CVE-2025-21629 Affects Linux Kernels, Not Windows Networking

The primary record tells a different timeline from the failed NVD page. NVD’s own change history shows the CVE record was received from kernel.org on January 15, 2025; Amazon Linux lists the public date as January 15, 2025 and says it was modified on February 12, 2025. NVD later added its CVSS assessment and affected-version analysis on October 16, 2025, followed by a reference update on November 3, 2025. The August 11, 2026 timestamp accompanying the 502 error is therefore best understood as a monitoring or retrieval timestamp, not a fresh disclosure date.

For administrators, the actionable item is straightforward: apply the kernel update supplied by the Linux distribution or update WSL itself if Windows is running WSL 2. There is no Microsoft Patch Tuesday KB associated with CVE-2025-21629.

The affected code is Linux networking offload logic​

The bug sits in

, in code that decides whether packet checksum work can be delegated to a network adapter. It concerns

, a legacy Linux network-device capability indicating that an adapter can calculate checksums for simple, unencapsulated IPv6 TCP or UDP packets.

That qualification—simple packets—is central. The feature is not supposed to apply when IPv6 extension headers are present. An earlier Linux change correctly prevented offload in that broader situation, but it also blocked a particular form of BIG TCP traffic that uses an IPv6 Hop-by-Hop Jumbo Payload option.

BIG TCP is a Linux feature intended to let TCP efficiently handle packets larger than conventional network limits in environments that support it. For IPv6, the kernel represents the oversized packet length through the Jumbo Payload extension header. The affected code treated that header like any other unsupported extension header and refused checksum offload, even though the BIG TCP header exists for local packet capture and segmentation handling rather than being emitted on the physical wire in the ordinary sense.

The result was not silent packet corruption or data exposure. The Linux kernel’s warning path,

, could trigger when it encountered a BIG TCP packet, and the workload could fall back into costly software handling. The upstream fix, committed as

for Linux 6.13-rc6, restores hardware checksum offload only when the kernel verifies that the packet has the specific BIG TCP Jumbo Payload header and no additional intervening IPv6 extension headers.

That is a deliberately narrow exception. It does not relax the general rule that

adapters cannot safely process arbitrary IPv6 extension-header traffic.

The security rating describes a local availability problem​

NVD assigned CVE-2025-21629 a CVSS 3.1 score of 5.5, classified as medium severity. The vector is local attack, low complexity, low privileges required, no user interaction, no confidentiality impact, no integrity impact, and high availability impact.

In plain terms, this is a denial-of-service and throughput-risk issue, not a remote code execution flaw and not a route to stealing traffic. A local, low-privileged actor still needs access to a Linux environment where the vulnerable kernel, the relevant network offload capability, and BIG TCP conditions all exist. That makes it much more relevant to shared Linux systems, appliance deployments, and specialized high-throughput networking environments than to a standard Windows desktop.

The report’s wording can sound more alarming than the real operating conditions. Simply having IPv6 enabled does not make a system demonstrably exposed. Simply using an Intel, Broadcom, or virtual network adapter does not establish exposure either. The fault requires a device that advertises the restricted IPv6 checksum-offload feature and a path that exercises BIG TCP.

Amazon Linux’s advisory independently rates the issue medium and uses the same 5.5 score. Its assessment is useful because it separates the flaw from vulnerabilities that can be reached over the network: the required attack vector is local, and the consequence is availability.

NVD’s version list is useful, but distribution packages remain the real patch boundary​

NVD identifies affected upstream Linux kernel ranges including 6.1.116 through 6.1.123, 6.6.60 through 6.6.69, Linux 6.12 before 6.12.9, and the 6.13 release candidates before the fix landed. It also identifies backported affected ranges on older stable branches, including 4.19, 5.4, 5.10, and 5.15.

Administrators should not treat that as a simple “compare

with an upstream release” exercise. Enterprise and long-term-support distributions routinely backport individual security fixes while retaining an older-looking base kernel version. A vendor kernel called

may be fixed even if its visible upstream version would otherwise fall in NVD’s affected range; conversely, a custom kernel compiled from an old stable tree may remain vulnerable long after a distribution has published a patched package.

Debian’s security tracker provides a concrete example. It records the upstream fix in Debian’s Bookworm kernel package at

, and its later Bullseye LTS kernel package at

. Amazon Linux 2023 shipped a fix in its January 24, 2025 kernel advisory. Those package-level records are more useful than generic version matching when deciding whether a managed host has actually received the correction.

The safer remediation sequence is:

• Apply the security kernel update supplied by the operating-system vendor rather than installing a random mainline kernel solely for this CVE.
• Reboot the host or otherwise confirm it has booted into the updated kernel; installing a package alone does not replace the running kernel.
• Check the running kernel with uname -r, then compare its full package revision against the vendor advisory for that distribution.
• Review custom kernels, frozen appliance images, and out-of-support distributions separately, because their patch status may not follow the distribution’s normal security channel.

WSL 2 is the Windows case worth checking​

Microsoft documents that WSL 2 runs an actual Linux kernel inside a lightweight managed virtual machine. That gives CVE-2025-21629 a possible Windows-adjacent footprint, but only in the WSL 2 architecture. WSL 1 does not run a full Linux kernel and is therefore outside this particular kernel bug’s scope.

For an ordinary, updated WSL 2 installation, the practical risk is low. BIG TCP is specialized, the required offload configuration is narrow, and modern WSL servicing should have moved the bundled kernel well beyond the affected Linux 6.6.60–6.6.69 window. But that conclusion should not be assumed for machines that use a pinned WSL package, blocked Microsoft Store servicing, an offline image, or a custom kernel specified through

.

Windows administrators can inspect WSL servicing and the installed kernel with

and

, then run

to obtain the current WSL package and kernel. Microsoft also notes that a WSL distribution’s user-space packages are maintained separately inside the distribution, so

or its equivalent remains necessary for the Linux userland—but it does not substitute for updating the WSL kernel itself.

A Windows PC with no WSL 2 installation, no Linux VM, and no Linux container host does not need a Windows update response for this CVE.

A later networking fix reinforces how narrow this exception must remain​

A follow-up Linux networking patch proposal published in August 2025 is an important piece of context. The Netdev discussion described a related but broader failure case on adapters exposing

without the newer

capability. On drivers such as

and

, Generic Segmentation Offload could attempt to use restricted IPv6 checksum offload for traffic with extension headers, producing warnings and—in observed GRE-over-IPv6 cases—throughput collapse.

That later work did not invalidate the CVE-2025-21629 fix. It explicitly preserved the BIG TCP exception while masking IPv6 checksum, TCP segmentation, and UDP segmentation offload for other irregular IPv6 header layouts. The distinction is operationally important: disabling IPv6 offload wholesale may avoid a warning, but it also sacrifices performance unnecessarily. The proper fix is to run the corrected kernel logic, which allows the specifically safe BIG TCP case while forcing unsupported extension-header traffic down a software checksum path.

CVE-2025-21629 should therefore be closed as a kernel-maintenance item, not escalated as a Windows emergency. Update the Linux kernel from the supported vendor channel, update WSL 2 where it is in use, and focus any deeper investigation on hosts that deliberately use BIG TCP or unusual IPv6 offload configurations.