CVE-2026-74666: Linux Kernel Race Condition Vulnerability

CVE-2026-74666 Overview

CVE-2026-74666 is a race condition in the Linux kernel's AF_PACKET subsystem. The flaw exists in packet_set_ring(), which updates the RX ring state under sk_receive_queue.lock but previously published the tpacket receive mode outside that lock. Concurrent calls to packet_poll() and packet_recvmsg() can execute the pressure clearing path after the ring is cleared while still observing tpacket_rcv, causing __packet_rcv_has_room() to dereference stale or NULL ring storage. The bug affects local, low-privilege users on systems where AF_PACKET sockets are available.

Critical Impact
Local attackers with CAP_NET_RAW can trigger a use-after-free or NULL pointer dereference in kernel space, enabling denial of service or potential local privilege escalation.

Affected Products

Linux kernel (mainline and stable branches prior to the fix commits)
Distributions shipping the affected net/packet/af_packet.c code path
Any workload permitting AF_PACKET socket creation with tpacket ring buffers

Discovery Timeline

2026-08-22 - CVE-2026-74666 published to NVD
2026-08-27 - Last updated in NVD database

Technical Details for CVE-2026-74666

Vulnerability Analysis

The vulnerability is a race condition [CWE-362] between AF_PACKET ring reconfiguration and packet receive processing paths. packet_set_ring() protects the ring buffer state transition with sk_receive_queue.lock. However, the original code published the receive hook function pointer (po->prot_hook.func) after releasing that lock.

This ordering creates a window where another CPU running packet_poll() or packet_recvmsg() can observe the old tpacket_rcv handler while the ring storage has already been torn down. The pressure clearing helper __packet_rcv_has_room() then dereferences stale or NULL ring pointers in kernel context.

The fix moves the receive hook assignment inside the same sk_receive_queue.lock critical section as the ring state update. It also serializes packet_recvmsg() pressure clearing behind the queue lock, but only after PACKET_SOCK_PRESSURE has been observed to avoid unnecessary contention.

Root Cause

The root cause is missing synchronization between the write side (ring reconfiguration in packet_set_ring()) and the read sides (packet_poll() and packet_recvmsg()). Publishing the receive mode outside the lock allowed readers to observe an inconsistent state where the hook still points at tpacket_rcv after the corresponding ring memory has been released.

Attack Vector

Exploitation requires local access and the CAP_NET_RAW capability, which is needed to open AF_PACKET sockets. An attacker races two threads: one repeatedly reconfigures the packet ring via setsockopt(PACKET_RX_RING), while another repeatedly calls poll() or recvmsg() on the same socket. Winning the race causes __packet_rcv_has_room() to dereference invalid memory, producing a kernel oops or, depending on heap layout, memory corruption suitable for privilege escalation.

No verified public proof-of-concept code is available. The vulnerability mechanism is documented in the upstream fix commits referenced below. See the kernel commit ad740b4 for the reference patch.

Detection Methods for CVE-2026-74666

Indicators of Compromise

Kernel oops or panic messages referencing __packet_rcv_has_room, packet_poll, or packet_recvmsg in dmesg and /var/log/kern.log
Unexpected process crashes or terminations for workloads using AF_PACKET sockets
Repeated setsockopt(PACKET_RX_RING) calls interleaved with poll() or recvmsg() from the same non-root PID

Detection Strategies

Audit AF_PACKET socket creation using auditd rules on the socket syscall with family AF_PACKET (17)
Monitor for processes holding CAP_NET_RAW that are not part of expected packet-capture tooling
Correlate kernel crash telemetry with prior userspace activity on the same PID to identify exploitation attempts

Monitoring Recommendations

Forward kern.log and dmesg output to a central SIEM for pattern matching on packet-subsystem stack traces
Baseline processes that legitimately require CAP_NET_RAW (tcpdump, Wireshark, DHCP clients) and alert on deviations
Track kernel version inventory across the fleet to prioritize hosts running unpatched builds

How to Mitigate CVE-2026-74666

Immediate Actions Required

Apply the upstream Linux kernel patches referenced in the vendor advisories and reboot affected systems
Restrict CAP_NET_RAW to trusted binaries and users via file capabilities or systemd unit hardening
Prioritize patching on multi-tenant hosts, container hosts, and systems permitting untrusted local users

Patch Information

The fix is available across multiple stable branches. Reference commits include 1a35da3, 2c7b5eb, 8cfb2e7, a08196c, ad740b4, bf3c8e8, cf8189b, and f015c9d. Consult your distribution's security tracker for backported package versions.

Workarounds

Drop CAP_NET_RAW from container capability sets using --cap-drop=NET_RAW in Docker or capabilities.drop in Kubernetes pod specs
Enforce seccomp profiles that block the socket syscall for AF_PACKET (family 17) in workloads that do not require raw packet access
Use SELinux or AppArmor policies to confine which binaries may open packet sockets on the host

bash

# Block AF_PACKET socket creation for untrusted containers via Docker
docker run --cap-drop=NET_RAW --security-opt=no-new-privileges <image>

# Kubernetes pod spec fragment
securityContext:
  capabilities:
    drop:
      - NET_RAW
  allowPrivilegeEscalation: false