CVE-2026-31700

What it actually does

This is a local time-of-check/time-of-use race in the Linux kernel AF_PACKET TPACKET transmit path. When PACKET_VNET_HDR is enabled, the kernel validates a virtio network header that resides in an mmap()'d TX ring shared with userspace, but later reads the same user-controlled memory again when building the socket buffer. A local attacker who can create the relevant packet socket can modify the header between validation and use, causing the kernel to act on values that were not validated. The likely impact is kernel memory corruption, crash, or local privilege escalation, reflected by high confidentiality, integrity, and availability impact. Exploitation requires local code execution and packet-socket capability, commonly CAP_NET_RAW or an equivalent capability obtained inside a user namespace or container configuration that permits AF_PACKET use.

Why it matters to the business

Successful exploitation can allow a local user, compromised workload, or container process with packet-socket privileges to crash the host kernel or potentially gain elevated privileges on the system. This is most relevant for multi-user Linux systems, container hosts, CI/build infrastructure, shared compute platforms, and environments that allow unprivileged user namespaces or grant CAP_NET_RAW to workloads. The issue is not known to be in CISA KEV, is not reported as ransomware-used, has very low EPSS, and has no listed public exploit maturity in the supplied data, so broad internet-scale exploitation is unlikely; however, the operational impact can still be severe where an attacker already has a foothold on a Linux host.

How an attack unfolds

An attacker first obtains local code execution on a Linux system, such as through a low-privileged shell, compromised application, or container workload. They then create an AF_PACKET socket and configure a TPACKET transmit ring with PACKET_VNET_HDR enabled, which causes the kernel to read virtio network header data from memory mapped into both userspace and kernel processing paths. The attacker uses one thread to submit packets through tpacket_snd() while another thread rapidly changes fields in the mmap'd virtio header after the kernel validation routine has accepted them but before virtio_net_hdr_to_skb() consumes them. By winning the race, the attacker makes the kernel use unsafe header values that bypass the original checks. Depending on kernel layout and exploit reliability, this can lead to kernel memory corruption, privilege escalation, or denial of service through a kernel oops or panic.

How to fix it

Apply the Linux kernel update from the relevant distribution or vendor that includes the fix for the AF_PACKET TPACKET PACKET_VNET_HDR race. No exact fixed versions were provided in the input, so remediation should be based on vendor advisories and changelogs confirming that the patch copying the mmap'd vnet_hdr to a stack-local variable before validation and use has been backported. Prioritize kernel updates on container hosts, shared Linux servers, virtualization hosts, CI runners, and systems that allow unprivileged user namespaces or grant CAP_NET_RAW. If immediate patching is not possible, reduce exposure by removing CAP_NET_RAW from containers and services, blocking AF_PACKET socket creation with seccomp/LSM policy where feasible, disabling or restricting unprivileged user namespaces where operationally acceptable, and limiting local shell/code-execution access. Reboot into the patched kernel after installation; merely installing a kernel package is not sufficient if the running kernel remains vulnerable.

How to confirm the fix worked

Confirm the running kernel, not just the installed package, is patched. Use uname -r and distribution package tools to verify the active kernel matches a vendor release that contains the backport for this issue. Review vendor changelogs or source patches for the AF_PACKET change in net/packet/af_packet.c where the virtio_net_hdr is copied from the mmap'd TX ring into a stack-local variable before validation and later use. Validate mitigations by confirming untrusted services and containers do not have CAP_NET_RAW, cannot create AF_PACKET sockets, and are constrained by seccomp or LSM policy where applicable. If unprivileged user namespaces were disabled as a mitigation, verify the relevant platform-specific setting, such as kernel.unprivileged_userns_clone=0 on systems that support it or a restrictive user.max_user_namespaces value. After patching, reboot and confirm that the active kernel version is the remediated one across all nodes.

Typical attack path

1. Gain local code execution on a Linux host or inside a workload with access to AF_PACKET sockets.
2. Ensure the process has the required packet-socket capability, commonly CAP_NET_RAW or equivalent privileges through a user namespace/container configuration.
3. Create an AF_PACKET socket and enable a TPACKET TX ring using PACKET_TX_RING.
4. Enable PACKET_VNET_HDR so the kernel consumes virtio network header data from the mmap'd ring buffer.
5. Map the TX ring into userspace with mmap().
6. Run concurrent threads: one submits packets through the TPACKET send path while the other modifies the shared vnet_hdr fields between validation and later use.
7. Trigger inconsistent kernel interpretation of the header, causing memory corruption, kernel crash, or potential privilege escalation.
8. Use any gained kernel-level control to escalate privileges, tamper with the host, or disrupt service.

How to detect it

There may be no reliable application-level evidence of exploitation because this is a local kernel race condition and exploitation occurs through normal system calls. Focus detection on host telemetry. Review kernel logs, journald, dmesg, rsyslog, and crash dump records for oops or panic events with stack traces mentioning AF_PACKET, tpacket_snd(), virtio_net_hdr_to_skb(), __packet_snd_vnet_parse(), packet_snd(), or net/packet/af_packet.c. Review auditd, eBPF, EDR, or syscall telemetry for suspicious local processes creating AF_PACKET sockets, enabling PACKET_TX_RING and PACKET_VNET_HDR, and mmap()'ing packet rings, especially from unexpected users, containers, CI jobs, or internet-facing application processes. Investigate processes or containers with CAP_NET_RAW that do not normally require raw packet access. Correlate any kernel crash or privilege-change event with preceding local process execution, container starts, unusual raw-socket activity, or exploit-like binaries compiled or executed from temporary directories. Because supplied intelligence indicates no known KEV listing, no ransomware association, very low EPSS, and no public exploit maturity, detection should be risk-based and focused on high-value or multi-tenant Linux hosts rather than assumed mass exploitation.

• tpacket_snd
• virtio_net_hdr_to_skb
• __packet_snd_vnet_parse
• packet_snd
• net/packet/af_packet.c
• PACKET_VNET_HDR
• PACKET_TX_RING
• AF_PACKET
• socket(AF_PACKET
• family=17
• CAP_NET_RAW
• BUG: kernel NULL pointer dereference
• BUG: unable to handle kernel paging request
• kernel panic
• Oops:
• general protection fault

What your security team should do

• Inventory Linux systems that run shared workloads, containers, CI jobs, or untrusted local code, and prioritize those for kernel patching.
• Patch and reboot affected Linux hosts using vendor kernel updates that include the AF_PACKET TPACKET vnet_hdr race fix.
• Remove CAP_NET_RAW from containers and services unless explicitly required.
• Block AF_PACKET socket creation for untrusted workloads using seccomp, AppArmor, SELinux, or container runtime policy where feasible.
• Restrict unprivileged user namespaces on systems where they are not required, because they can expand access to capabilities used by local kernel exploits.
• Monitor kernel logs for oops, panic, or warning stack traces involving tpacket_snd, virtio_net_hdr_to_skb, __packet_snd_vnet_parse, or packet sockets.
• Enable or tune audit/eBPF telemetry for AF_PACKET socket creation and packet-ring setsockopt activity on high-risk multi-tenant systems.
• Treat unexplained kernel crashes on systems with local untrusted users or container workloads as potentially suspicious and preserve logs, crash dumps, and workload metadata for analysis.