CVE-2026-52910

What it actually does

This is a Linux kernel use-after-free in the socket reuseport/BPF path. A classic BPF program attached to a UDP SO_REUSEPORT group can be freed immediately while another CPU is still using it under an RCU read-side critical section in reuseport_select_sock(). The race occurs when one thread replaces or detaches the reuseport cBPF program via setsockopt() while another thread sends or receives UDP traffic for the same reuseport group. The observed failure is a KASAN vmalloc out-of-bounds read in kernel networking code; depending on kernel configuration and memory layout, the practical impact is likely local denial of service through kernel crash, with possible kernel memory corruption risk.

Why it matters to the business

Systems running affected Linux kernels may be vulnerable to local disruption by users, workloads, or containers that can create UDP sockets and attach or replace reuseport classic BPF programs. Successful exploitation can crash the host kernel or destabilize networking, causing service outages for applications on the same server. The vulnerability is not currently listed in CISA KEV, is not known to be used in ransomware campaigns, has low EPSS probability, and has no public exploit maturity indicated, but it affects a core operating-system component and should still be prioritized for kernel maintenance windows.

How an attack unfolds

An attacker first needs the ability to execute code on the Linux system, such as through a local shell, compromised application process, or permissive container workload. They create a UDP SO_REUSEPORT socket group and attach a classic BPF reuseport selector program. In one execution thread, they repeatedly replace or detach that cBPF program using setsockopt(); in another thread, they send UDP packets to exercise the reuseport selection fast path. Because the old cBPF program may be freed before all RCU readers finish, the networking receive path can dereference freed program memory in reuseport_select_sock(). The result is kernel memory-safety failure, commonly visible as a KASAN report, kernel oops, panic, or host networking instability. No remote-only exploitation path is indicated by the supplied information; exploitation is primarily local or from code already running on the host.

How to fix it

Apply the Linux kernel update from the relevant distribution or kernel vendor that includes the fix for deferring reuseport cBPF program freeing until after an RCU grace period. No exact fixed package versions were provided, so use vendor advisories, package changelogs, or kernel stable backport notes to identify the corrected build. After installing the kernel, reboot the host so the patched kernel is active. Where immediate patching is not possible, reduce exposure by preventing untrusted local code execution, tightening container privileges, using seccomp/AppArmor/SELinux policies to restrict risky socket setsockopt() usage where feasible, and limiting workloads that can create UDP SO_REUSEPORT groups with attached BPF filters. Disabling unprivileged eBPF may be beneficial for general BPF hardening but should not be treated as a complete mitigation for this classic socket-BPF reuseport issue.

How to confirm the fix worked

Confirm the running kernel, not only the installed package, is updated by checking uname -r and comparing it with the vendor-fixed kernel version or advisory. Review the kernel package changelog or source tree for the fix associated with deferring reuseport cBPF program freeing after an RCU grace period, commonly described as 'bpf: Free reuseport cBPF prog after RCU grace period.' Reboot verification is required because kernel updates do not protect the system until the new kernel is running. On test systems, a controlled reproducer that races SO_REUSEPORT cBPF replacement with UDP traffic should no longer produce KASAN, oops, or panic output. Also verify that crash logs no longer show reuseport_select_sock() use-after-free or vmalloc out-of-bounds reports.

Typical attack path

1. Gain local code execution on a Linux host or inside a workload with sufficient socket access.
2. Create multiple UDP sockets using SO_REUSEPORT.
3. Attach a classic BPF reuseport program to the socket group.
4. Race two operations: repeatedly replace or detach the reuseport cBPF program while concurrently sending UDP packets through the group.
5. Trigger reuseport_select_sock() to access the freed cBPF program before the RCU grace period completes.
6. Cause kernel memory corruption symptoms such as KASAN splats, kernel oops, panic, or networking instability.

How to detect it

Look for evidence in kernel and system logs rather than network perimeter indicators. Review journalctl -k, dmesg, /var/log/kern.log, /var/log/messages, crash dumps, and pstore/ramoops for KASAN reports, kernel oopses, panics, or stack traces referencing UDP reuseport selection and BPF program freeing. Pay particular attention to crashes where reuseport_select_sock(), udp4_lib_lookup2(), __udp4_lib_rcv(), sk_reuseport_prog_free(), bpf_release_orig_filter(), or bpf_prog_free() appear together. If auditd, eBPF telemetry, syscall tracing, or EDR telemetry is available, hunt for local processes repeatedly calling setsockopt() with SO_REUSEPORT and SO_ATTACH_REUSEPORT_CBPF/SO_DETACH_REUSEPORT_BPF while generating high-rate UDP sendto() traffic. Correlate suspicious activity with container IDs, service accounts, recently deployed workloads, or binaries that are not expected to manipulate reuseport BPF programs. There are no known threat actors, ransomware campaigns, or stable remote network signatures provided for this issue.

• BUG: KASAN: vmalloc-out-of-bounds in reuseport_select_sock
• reuseport_select_sock+
• net/core/sock_reuseport.c
• sk_reuseport_prog_free
• bpf_release_orig_filter
• bpf_prog_free
• udp4_lib_lookup2
• __udp4_lib_rcv
• SO_ATTACH_REUSEPORT_CBPF
• SO_DETACH_REUSEPORT_BPF
• SO_REUSEPORT
• KASAN: vmalloc-out-of-bounds
• kernel oops in reuseport_select_sock
• panic in reuseport_select_sock

What your security team should do

• Prioritize patching Linux kernels on multi-tenant, container-hosting, CI/CD, edge, and high-availability systems where untrusted or semi-trusted code can run locally.
• Identify hosts running affected kernel lines and schedule reboots after applying vendor-fixed kernel packages.
• Monitor kernel logs for KASAN, oops, panic, or stack traces involving reuseport_select_sock(), sk_reuseport_prog_free(), bpf_release_orig_filter(), or bpf_prog_free().
• Review container and sandbox policies to reduce access to advanced socket options and unnecessary BPF-related functionality for untrusted workloads.
• Treat unexpected kernel crashes involving UDP reuseport or BPF paths as potentially security-relevant, preserve crash dumps, and investigate recent local process activity.
• Do not rely on EPSS or non-KEV status alone to defer remediation on shared Linux hosts, because local kernel denial-of-service issues can have broad operational impact.