A vulnerability in the Linux kernel’s network emulation queuing discipline (netem) can cause memory corruption under specific tunnel conditions. Patches have been released across multiple stable kernel branches, and Microsoft’s Security Update Guide now tracks the issue as CVE-2026-31675. While the flaw resides in Linux, it has direct implications for Windows administrators running Linux workloads in WSL, Azure, Hyper-V, and container environments. The fix is available now, and understanding your exposure is the first step toward mitigation.

What Just Happened?

On April 25, 2026, the Linux kernel project disclosed a bug in the sch_netem traffic-control module. Netem is a tool used by developers and network engineers to simulate impaired networks—delays, packet loss, duplication, and corruption. The vulnerability lies in netem’s packet corruption feature, which, under a rare combination of parameters, could access data outside the intended packet buffer, potentially leading to memory corruption or kernel crashes.

The trigger requires a specific setup: AF_PACKET TX_RING sockets transmitting fully non-linear packets through an IPIP tunnel while netem’s corruption option is active. When a packet’s linear data area is completely empty (skb_headlen() returns zero), the old code still attempted to select a random byte inside that nonexistent region, leading to an out-of-bounds memory operation.

The fix, already backported to stable kernel series 6.6.134, 6.12.81, 6.18.22, 6.19.12, and mainline 7.0, adds a simple check: if there is no linear data to corrupt, skip the corruption step entirely.

Which Systems Are at Risk?

Not every Linux machine is exposed. The vulnerable code path is activated only when all of the following are true:

  • The netem queuing discipline is attached to a network interface.
  • That qdisc is configured with the corrupt option (not just delay or loss).
  • The traffic passing through it includes fully non-linear socket buffers—a condition that can arise from AF_PACKET TX_RING, certain tunnel encapsulations, or scatter-gather I/O.
  • IPIP tunneling is in use.
  • The system runs an unpatched kernel version.

In practice, this limits the immediate risk to lab environments, CI/CD pipelines, network testbeds, and specialized production setups that deliberately simulate network damage. However, because netem is a standard part of the Linux traffic-control subsystem, it is available on nearly all distributions, often loaded as a kernel module by default.

The Technical Breakdown

The core issue is a bounds-checking failure inside netem_enqueue(). Normally, when netem is asked to corrupt a packet, it calls get_random_u32_below() with the ceiling set to skb_headlen(skb), the length of the packet’s linear data portion. If that length is zero, the function—contrary to its name—does not return a number below zero; instead, it falls back to a generic 32-bit random value. That unbounded value is then used as an offset into the packet’s memory, potentially reading or writing far outside the intended buffer.

Fully non-linear packets, where all payload resides in fragmented page buffers rather than a contiguous header area, are legitimate constructs in high-performance networking. The bug emerges when two design assumptions collide: netem expects at least one corruptible linear byte, and certain tunnel configurations produce exactly zero such bytes.

The upstream fix, a single-line guard, prevents the random offset from being generated if skb_headlen(skb) == 0, silently passing the packet through without corruption. This is a conservative change that preserves stability while leaving future improvements (like corrupting non-linear fragments) to a separate discussion.

Why This Matters for Windows Environments

CVE-2026-31675 is not a Windows kernel vulnerability. No Windows update is required to protect a standard Windows desktop or server. But in modern Microsoft-centric organizations, Linux is everywhere:

  • Windows Subsystem for Linux (WSL) runs a Microsoft-provided Linux kernel that may be affected if not updated.
  • Azure virtual machines often run Linux guest operating systems, and many cloud-native services are built on Linux containers.
  • Azure Kubernetes Service (AKS) nodes and self-managed clusters run Linux kernels that could carry the bug.
  • Hyper-V Linux guests used for network simulation or testing may have netem enabled.
  • CI/CD pipelines frequently install tc (traffic control) tools to simulate network impairments during integration tests.

Microsoft’s Security Update Guide now lists CVE-2026-31675 to provide visibility into ecosystem threats. For administrators who manage hybrid fleets, the message is clear: inventory your Linux systems, check their kernel versions, and verify that patched kernels are running—not just installed.

How to Protect Your Systems

1. Patch Your Linux Kernels

The most direct remediation is a kernel update. Consult your distribution’s security advisory for the exact fixed package version. The following upstream stable releases already contain the fix, but downstream vendors may backport it to older version numbers:

Upstream Version Status
6.6.134 Patched
6.12.81 Patched
6.18.22 Patched
6.19.12 Patched
7.0 (mainline) Patched

After updating, reboot the system (or use live patching if supported) and verify the running kernel with uname -r.

2. Reduce Attack Surface

Even without an immediate patch, you can minimize exposure by removing unnecessary privileges and configurations:

  • Audit qdisc rules: Run tc qdisc show and look for netem with the corrupt keyword. If it’s not required, replace it with a safer alternative or delete it.
  • Restrict capabilities: In containers and non-root user namespaces, drop CAP_NET_ADMIN and CAP_NET_RAW unless explicitly needed. These capabilities are often over-allocated in development environments.
  • Disable unused tunnels: If IPIP interfaces exist on systems that don’t require them, remove them (ip link del).
  • Review CI/CD scripts: Many test harnesses install tc and apply qdisc rules. Ensure they don’t enable corruption unless the test specifically requires it, and run such tests in isolated, disposable environments.
  • Harden WSL: On developer workstations, check the WSL kernel version (uname -r inside the instance) and upgrade if it predates the fix. The Microsoft WSL kernel is updated through Windows Update or the Microsoft Store, depending on your configuration.

3. Validate Patch Effectiveness

Because the vulnerability is a memory-safety issue, exploitation is unlikely to leave obvious application-layer logs. Instead, monitor for kernel warnings, KASAN reports, or sudden crashes during packet-emulation tests. The most reliable indicator is a kernel version string that matches a fixed release. Use configuration management tools to assert that the running kernel is compliant.

The Patch Landscape

As of this writing, the National Vulnerability Database (NVD) has not yet assigned a CVSS severity score to CVE-2026-31675. That absence should not delay action. Many kernel CVEs follow this pattern: the fix is committed, the CVE record is published, and severity enrichment lags behind. Administrators must assess risk based on their own asset inventory and configuration state.

Distribution vendors are in various stages of releasing advisories. Red Hat, Canonical, SUSE, and Debian will typically publish their own severity ratings and fixed package versions. Microsoft’s role, beyond acknowledging the CVE in its Security Update Guide, is to update its managed Linux images—such as those in Azure Marketplace and AKS—to patched kernel builds. Azure users should check the relevant security bulletin for their service tier.

For WSL, Microsoft controls kernel delivery differently depending on the WSL version and distribution model. Users on the default Microsoft-provided kernel will likely receive the fix through Windows Update or an updated WSL package. Those using custom kernels (common in enterprise environments) must patch manually.

The Bigger Picture for Windows Shops

This vulnerability is a textbook example of why hybrid security management demands a unified inventory of all computing environments—not just Windows endpoints. A Microsoft-heavy organization may still be running unpatched Linux kernels inside build agents, monitoring appliances, network testing labs, or container hosts. Security scanners that rely solely on upstream version strings may misclassify backported fixes, causing false alarms or dangerous blind spots.

The CVE also highlights a supply-chain lesson: even esoteric features like a network emulator’s corruption mode can become an attack surface if the kernel code is shared across all workloads. Container platforms, in particular, should keep capability defaults conservative. Granting CAP_NET_ADMIN to every container because it’s “just a lab” is an open invitation for kernel vulnerabilities to become operational threats.

What Comes Next

Over the coming weeks, the story will likely evolve in three directions:

  1. CVSS scoring – Once NVD completes its analysis, the industry will have a formal severity rating. Expect a moderate or medium score given the local nature and specialized trigger.
  2. Public proof-of-concept – Researchers may publish reliable reproducers, lowering the barrier for exploit development. While immediate remote exploitation seems unlikely, local privilege escalation or information disclosure might be demonstrated.
  3. Scanner updates – Vulnerability scanners will add detection rules, potentially flagging millions of unpatched Linux kernels. Differentiating between upstream versions and vendor-backported fixes will be critical to avoid alert fatigue.

For Windows administrators, the takeaway is straightforward: Linux kernel security is now part of your patch governance, whether or not you have “Linux” in your job title. Check your WSL instances, audit your cloud nodes, and ensure that any system running tc netem corrupt is either removed or running a fixed kernel. The bug may be in the lab tool, but its impact can land in production.