CVE-2026-52938: Linux Kernel Use-After-Free Vulnerability

CVE-2026-52938 Overview

CVE-2026-52938 is a NULL pointer dereference vulnerability in the Linux kernel's Berkeley Packet Filter (BPF) socket storage subsystem. The flaw resides in bpf_sk_storage_clone() and the BPF diagnostic paths in net/core/bpf_sk_storage.c. A race condition allows a concurrent Read-Copy-Update (RCU) reader to observe a socket storage element (selem) still attached to the storage hash list while its smap pointer has already been set to NULL by bpf_selem_unlink_nofail(). Dereferencing the NULL smap triggers a general protection fault in kernel context, as confirmed by KernelAddressSanitizer (KASAN) reports.

Critical Impact
A concurrent RCU reader can dereference a NULL smap pointer during socket cloning on inbound TCP SYN handling, causing a kernel general protection fault and denial of service.

Affected Products

Linux kernel versions containing the vulnerable bpf_sk_storage implementation
Distributions shipping pre-patch upstream kernels with BPF socket storage enabled
Systems using BPF socket-local storage features (eBPF programs attaching per-socket state)

Discovery Timeline

2026-06-24 - CVE-2026-52938 published to the National Vulnerability Database (NVD)
2026-06-24 - Last updated in NVD database

Technical Details for CVE-2026-52938

Vulnerability Analysis

The vulnerability is a kernel-mode NULL pointer dereference triggered by a race between BPF socket storage element teardown and concurrent RCU readers. bpf_selem_unlink_nofail() clears SDATA(selem)->smap to NULL before unlinking the element from the storage hlist. During this window, an RCU reader walking the list still observes the element as a valid member, but the embedded smap pointer is already NULL.

In the reported crash, the reader path is bpf_sk_storage_clone() invoked during sk_clone() on the TCP receive path. When a new socket is created from a listen socket on receipt of a SYN-ACK or final ACK, the cloning logic copies BPF socket-local storage entries. Dereferencing the NULL smap produces a general protection fault, as shown in the KASAN trace at bpf_sk_storage_clone+0x1cd/0xaa0. The same defect is present in bpf_sk_storage_diag_put_all(), which reads smap through a selem reference rather than from the validated diag->maps[i] reference held under refcount.

Root Cause

The root cause is an ordering bug in the unlink sequence. The code nullifies SDATA(selem)->smap before removing selem from the hash list, breaking the invariant that any list-visible element has a non-NULL smap. This is a classic concurrency defect [CWE-476] compounded by a TOCTOU-style window between observation and dereference [CWE-367].

Attack Vector

Triggering the race requires the target kernel to load a BPF program that registers socket-local storage and a workload that simultaneously creates and tears down sockets bound to that storage. The crash trace shows the path reached through inbound TCP handshake processing (tcp_v4_rcv → tcp_check_req → tcp_v4_syn_recv_sock → inet_csk_clone_lock → sk_clone → bpf_sk_storage_clone). A local user with privileges to load BPF programs, or a remote attacker who can drive TCP connection establishment against a host running such BPF programs, can race the unlink path to produce a kernel oops and denial of service. The patch adds a NULL check for smap in bpf_sk_storage_clone() and refactors diag_get() to accept a validated smap from the caller.

Detection Methods for CVE-2026-52938

Indicators of Compromise

Kernel oops or general protection fault messages referencing bpf_sk_storage_clone+0x1cd in dmesg or /var/log/kern.log
KASAN reports indicating null-ptr-deref in range [0x0000000000000050-0x0000000000000057] from BPF socket storage code paths
Unexpected kernel panics correlated with high TCP connection establishment rates on hosts running BPF socket-storage programs

Detection Strategies

Inventory loaded BPF programs and maps with bpftool prog show and bpftool map show to identify hosts using BPF_MAP_TYPE_SK_STORAGE.
Compare running kernel versions against vendor advisories that backport commit 375e4e33c18dfa05c5dfd5f3dfffeb29343dd4c7.
Collect kernel crash dumps via kdump and inspect call stacks for bpf_sk_storage_clone or bpf_sk_storage_diag_put_all frames.

Monitoring Recommendations

Forward kernel logs to a centralized SIEM and alert on repeated general protection fault events tagged with BPF socket storage symbols.
Track host availability and unexpected reboots on systems serving high-throughput TCP workloads with BPF instrumentation.
Monitor BPF program load events via audit subsystem rules on the bpf() syscall to identify untrusted code introducing socket storage maps.

How to Mitigate CVE-2026-52938

Immediate Actions Required

Apply the upstream Linux kernel fix referenced by commit 375e4e33c18dfa05c5dfd5f3dfffeb29343dd4c7 or the corresponding stable backport from your distribution.
Restrict CAP_BPF and CAP_SYS_ADMIN to trusted administrators to limit who can load BPF programs that exercise socket-local storage.
Audit third-party agents and observability tooling that load BPF programs using BPF_MAP_TYPE_SK_STORAGE and confirm they run on patched kernels.

Patch Information

The fix adds a NULL check for smap inside bpf_sk_storage_clone() so that an RCU reader skips a selem whose smap has been cleared. bpf_sk_storage_diag_put_all() is updated with the same NULL check, and diag_get() is refactored to accept a validated smap parameter from the caller instead of reading it from the selem. In bpf_sk_storage_diag_put(), diag->maps[i] remains valid under refcount and is passed directly. See the Linux Kernel Commit Patch for the authoritative change.

Workarounds

Unload non-essential BPF programs that allocate per-socket storage until the kernel patch is deployed.
Set kernel.unprivileged_bpf_disabled=1 via sysctl to prevent unprivileged users from loading BPF programs.
Where feasible, restrict ingress TCP connection rates on exposed services running susceptible BPF instrumentation to reduce the race window.

bash

# Configuration example
sudo sysctl -w kernel.unprivileged_bpf_disabled=1
echo 'kernel.unprivileged_bpf_disabled=1' | sudo tee /etc/sysctl.d/90-bpf-hardening.conf
sudo bpftool prog show
sudo bpftool map show | grep -i sk_storage