CVE-2026-31675

What it actually does

This is a Linux kernel memory-corruption flaw in the sch_netem traffic-control scheduler. When netem packet corruption is enabled, the kernel selects a random byte offset within the packet’s linear data area. For fully non-linear socket buffers, skb_headlen(skb) can be zero; the vulnerable path passes that zero length into get_random_u32_below(), which can return an unconstrained 32-bit value. That value is then used as an offset into skb->data, causing an out-of-bounds memory access in kernel context. Depending on kernel configuration, memory layout, hardening, and exploit reliability, the result may be kernel crash, memory disclosure, data corruption, or potential local privilege escalation. Exploitation is local and requires an attacker to be able to create the relevant packet path, such as AF_PACKET TX_RING traffic through an IPIP tunnel and a netem qdisc with corruption enabled.

Why it matters to the business

A local user or compromised workload with sufficient networking capabilities could destabilize the host kernel or potentially gain elevated privileges, affecting confidentiality, integrity, and availability of systems that allow advanced network features such as traffic control, packet sockets, tunnels, or network namespaces. The issue is not currently listed in CISA KEV, has very low EPSS, no known mature public exploit, and is not known to be used in ransomware campaigns, so broad internet-scale exploitation is unlikely; however, shared Linux hosts, container platforms, CI runners, labs, and systems granting CAP_NET_ADMIN or CAP_NET_RAW should treat it as higher priority because local kernel flaws can turn limited footholds into host compromise.

How an attack unfolds

An attacker first obtains local code execution as a low-privileged user or inside a workload that has access to packet sockets and the ability to influence traffic-control/tunnel configuration, commonly through Linux capabilities, user/network namespaces, or an already misconfigured privileged container. The attacker arranges a traffic path where packets traverse sch_netem with packet corruption enabled, then sends specially shaped fully non-linear packets using AF_PACKET TX_RING over an IPIP tunnel. In the vulnerable kernel path, netem_enqueue() attempts to corrupt a byte in the packet’s linear data area even though that area has zero length. Because the random offset calculation is called with a zero upper bound, the returned offset can be outside the packet buffer, leading to an out-of-bounds kernel memory access. A simple attempt may panic or oops the kernel, while a more developed exploit would try to shape memory layout and packet contents to convert the out-of-bounds access into privilege escalation or controlled kernel memory corruption. No public mature exploitation is currently indicated by the provided data.

How to fix it

Upgrade to a Linux kernel version that includes the upstream fix for sch_netem’s packet corruption logic, which checks that skb_headlen(skb) is non-zero before modifying the linear data area. Because no exact fixed package versions were provided, use distribution security advisories from the relevant vendor and install the latest kernel security update for all affected Linux systems. Reboot into the updated kernel after installation; simply installing the package is not sufficient if the running kernel remains vulnerable. As mitigations until patching is complete, restrict CAP_NET_ADMIN and CAP_NET_RAW, avoid privileged containers, disable unneeded user namespaces where operationally feasible, limit access to traffic-control configuration tools such as tc, remove or disable unnecessary IPIP tunnels, and avoid enabling netem packet corruption on systems where untrusted users or workloads can influence packet generation.

How to confirm the fix worked

Confirm the running kernel, not just the installed kernel package, has been updated using uname -r and the distribution package manager. Validate that vendor advisories for the deployed kernel stream mark this issue as fixed. Where source or build metadata is available, verify the net/sched/sch_netem.c fix that skips corruption when skb_headlen(skb) is zero. Review active qdisc configuration with tc qdisc show and identify any netem qdiscs using corruption settings. Review tunnel configuration with ip tunnel show for IPIP use. Confirm that untrusted users and containers do not have CAP_NET_ADMIN or CAP_NET_RAW unless explicitly required. If regression testing is available, exercise netem corruption with packet/tunnel workloads and verify there are no kernel oops, KASAN, or panic messages associated with netem_enqueue().

Typical attack path

1. Gain local code execution on a Linux system, container host, or workload with access to relevant networking capabilities.
2. Confirm the ability to use AF_PACKET/TX_RING, create or use an IPIP tunnel, and configure or reach a netem qdisc with packet corruption enabled.
3. Craft fully non-linear packets so that skb_headlen(skb) is zero when processed by netem_enqueue().
4. Send the packets through the IPIP/netem path to trigger the packet corruption logic.
5. Cause an out-of-bounds access in kernel memory via an unconstrained random offset into skb->data.
6. Use the resulting condition to crash the host or, with additional exploit engineering, attempt kernel memory corruption and privilege escalation.

How to detect it

Detection should focus on evidence of attempted trigger conditions and post-exploitation symptoms rather than a single definitive network signature. Review kernel logs from journald, syslog, dmesg, crash dumps, and EDR telemetry for kernel oops, panic, KASAN, UBSAN, or general protection fault messages referencing netem_enqueue, sch_netem, skb_headlen, skb->data, or out-of-bounds access. Review auditd, shell history, sudo logs, process execution telemetry, and container runtime logs for tc qdisc commands that add or change netem corruption settings, IPIP tunnel creation, or unusual packet-socket tooling. Review capability assignments for processes and containers with CAP_NET_ADMIN or CAP_NET_RAW. On hosts that crashed unexpectedly, preserve vmcore/kdump artifacts and inspect stack traces for net/sched/sch_netem.c or packet/tunnel code paths. Because legitimate network simulation can use netem, correlate suspicious commands with unapproved users, unusual containers, recent privilege changes, IPIP tunnel creation, and system instability.

• netem_enqueue
• sch_netem
• get_random_u32_below
• skb_headlen
• skb->data
• KASAN: slab-out-of-bounds
• KASAN: out-of-bounds
• BUG: unable to handle kernel paging request
• general protection fault
• kernel BUG at net/sched/sch_netem.c
• Oops:
• panic
• tc qdisc add
• tc qdisc change
• netem corrupt
• ip tunnel add
• mode ipip
• AF_PACKET
• PACKET_TX_RING
• CAP_NET_ADMIN
• CAP_NET_RAW

What your security team should do

• Patch affected Linux kernels during the next security maintenance window, prioritizing multi-tenant hosts, container platforms, CI/CD runners, developer workstations with local untrusted code execution, and systems granting advanced networking capabilities.
• Inventory systems using netem, traffic-control emulation, IPIP tunnels, AF_PACKET-heavy applications, privileged containers, or workloads with CAP_NET_ADMIN/CAP_NET_RAW.
• Restrict or remove CAP_NET_ADMIN and CAP_NET_RAW from containers and services that do not strictly require them.
• Audit use of tc qdisc commands, especially netem corruption settings, on production systems.
• Monitor kernel logs for crashes or memory-safety reports involving netem_enqueue, sch_netem, skb_headlen, or out-of-bounds access.
• Treat unexpected kernel oops or panic events on systems using netem/IPIP as potential exploitation until investigated.
• Because this is not KEV, has low EPSS, and has no known mature exploit, balance urgency against exposure: capability-exposed shared hosts should be prioritized over isolated single-user systems.