CVE-2026-52910: Linux Kernel UDP Reuseport BPF Use-After-Free Race Condition

Technical summary

CVE-2026-52910 addresses a use-after-free vulnerability in the Linux kernel's reuseport socket mechanism. The vulnerability occurs in the socket reuse port group's BPF program management, specifically in the function sk_reuseport_prog_free(). When a cBPF (classic BPF) program is detached via setsockopt() (through reuseport_attach_prog or reuseport_detach_prog), the old program is freed immediately without synchronizing with RCU (Read-Copy-Update) grace periods. Concurrently, the UDP packet processing path (udp4_lib_lookup2 → reuseport_select_sock) may still be reading the freed program's fields, resulting in out-of-bounds memory access. The fix defers cBPF program freeing until after one RCU grace period completes, ensuring all in-flight packet lookups finish before memory is reclaimed. Extended BPF (eBPF) programs use a separate multi-stage destruction path (bpf_prog_put_deferred) that already respects RCU semantics and are not affected by this particular race.

Business impact

Systems running vulnerable Linux kernels face availability risk from kernel panics triggered by legitimate UDP traffic interacting with reuseport BPF programs. In containerized and multi-tenant environments where reuseport load balancing is common, an unprivileged user could crash the shared kernel by timing program attachment changes with incoming packets. While the CVSS score reflects high severity due to the integrity and availability impact, real-world exploitation requires precise thread timing and local system access; however, the low barrier to trigger the condition in production workloads makes this a meaningful stability concern for systems using reuseport BPF features.

Affected systems

All Linux kernel versions implementing reuseport BPF program attachment are affected. The vulnerability requires a kernel with BPF and reuseport support enabled (CONFIG_BPF and SO_REUSEPORT). Notably, this does not require the attacker to have root privileges; any local unprivileged user can trigger the race by attaching BPF programs to UDP sockets they own. Container hosts, load balancers, and any system where multiple processes bind to the same UDP port via SO_REUSEPORT are at heightened risk.

Exploitability

The vulnerability is exploitable without special privileges and requires only local system access. An attacker must: (1) create a UDP socket with SO_REUSEPORT enabled; (2) attach a BPF program to the socket group; (3) replace or detach the program via setsockopt while (4) another process simultaneously receives UDP packets on the group. The race window is narrow but reliably reproducible as demonstrated in the reported test case. No network access, authentication, or elevated privileges are needed. However, triggering the exact race condition in production traffic patterns may require trial or specific timing; exploitation is not automatic but feasible for determined actors with local access.

Remediation

Apply the upstream Linux kernel patch that wraps the cBPF program freeing operation (bpf_release_orig_filter and bpf_prog_free) in an RCU-deferred callback, ensuring the memory is not reclaimed until after rcu_read_unlock() completes on all CPUs. This aligns cBPF program lifetime management with eBPF semantics. Verify the patch is included in the stable kernel version shipped by your distribution, as kernel maintainers typically backport critical RCU-related fixes across supported branches. No workaround at the application level can reliably mitigate the race; a kernel update is required.

Patch guidance

Identify which kernel series your systems run (check via `uname -r`). Contact your Linux distribution vendor to obtain the patched kernel version for your branch (e.g., RHEL, Ubuntu LTS, Debian stable). The patch is expected to be available in: (1) upstream kernel versions released after the fix was merged; (2) stable kernel branches (6.1.x, 6.6.x, 6.9.x, etc.) in their next maintenance release; (3) distribution point releases. Do not rely on upstream kernel.org alone; wait for your vendor's official release to ensure compatibility and testing. Test the patched kernel in a non-production environment first, especially if you rely on SO_REUSEPORT for load balancing.

Detection guidance

Monitor kernel logs (dmesg, journalctl -k) for "KASAN: vmalloc-out-of-bounds" or "BUG: unable to handle page fault" messages correlated with reuseport_select_sock or UDP packet processing activity. Systemtap or eBPF tracing can instrument sock_reuseport_prog_free() calls and cross-reference them with active reuseport lookups to identify unpatched systems under simultaneous load. In production, memory sanitizer output (if KASAN is enabled) will clearly log the out-of-bounds read. However, detection of *attempted* exploitation (rather than crash forensics) is difficult without kernel-level instrumentation; focus on timely patching rather than detection strategies.

Why prioritize this

Despite not appearing on the KEV list, this vulnerability merits high priority for systems actively using UDP reuseport load balancing (common in CDNs, DNS servers, game servers, and container orchestration). The combination of (1) local exploitability without privilege escalation, (2) guaranteed availability impact (kernel panic), and (3) relative ease of triggering the race in multi-threaded or containerized environments makes this a material risk. Organizations with multi-tenant Kubernetes clusters or shared hosting should prioritize patching. Lower priority for systems that do not bind multiple UDP sockets to the same port, or those running kernels predating reuseport BPF support.

Risk score, explained

The CVSS 3.1 score of 7.8 (HIGH) reflects: Attack Vector (Local—requires system access), Attack Complexity (Low—race is reliably triggerable), Privileges Required (Low—no elevation needed), User Interaction (None), Scope (Unchanged), and impact on Confidentiality (High due to potential information leak from freed memory), Integrity (High—overwriting freed memory), and Availability (High—kernel crash). The score appropriately captures the severity despite the KEV status being false (KEV likely focuses on active exploitation in the wild rather than theoretical feasibility). Real-world impact can be severe in dense containerized environments where many processes manage ephemeral UDP sockets.

Frequently asked questions