CVE-2026-52938

What it actually does

This vulnerability is a race-condition NULL pointer dereference in the Linux kernel BPF socket storage code. During concurrent socket storage unlinking and RCU-protected reads, bpf_selem_unlink_nofail() can clear the storage map pointer before the element is removed from the list. A concurrent reader in bpf_sk_storage_clone() or related diagnostic paths can then dereference a NULL smap pointer, triggering a kernel general protection fault or panic depending on kernel configuration. The practical technical impact is local or network-adjacent denial of service through kernel crash conditions; the available description does not indicate privilege escalation, data disclosure, or code execution.

Why it matters to the business

Systems running affected Linux kernel versions may become unstable or crash if the vulnerable BPF socket storage path is triggered, causing service interruption, failed connections, workload restarts, or host reboots. The current EPSS score is very low, it is not listed in CISA KEV, and no public exploit maturity is reported, so broad active exploitation is not currently indicated; however, kernel-level denial-of-service bugs should still be prioritized for internet-facing, high-availability, container-hosting, and multi-tenant Linux systems where outages have direct operational impact.

How an attack unfolds

An attacker would need to trigger the vulnerable kernel execution path involving BPF socket storage while socket cloning or diagnostic processing occurs concurrently with storage element removal. In a plausible scenario, the attacker first obtains the ability to run code or otherwise influence BPF/socket behavior on a vulnerable Linux host, then creates conditions that exercise BPF socket local storage, connection cloning, and teardown at high concurrency. If the timing race is won, the kernel observes a storage element that remains linked while its map pointer has already been cleared, causing a NULL pointer dereference in bpf_sk_storage_clone() or bpf_sk_storage_diag_put_all(). The result is a kernel fault that may panic the host or disrupt affected networking services. The vulnerability is primarily a stability and availability issue rather than a direct remote compromise based on the provided information.

How to fix it

Apply a Linux kernel update that includes the fix adding validated NULL checks for smap in bpf_sk_storage_clone() and bpf_sk_storage_diag_put_all(), and the related diagnostic path refactoring. Because exact affected package names and fixed versions were not provided, use the fixed kernel packages from the operating system or distribution vendor advisory for this CVE. Where immediate patching is not possible, reduce exposure by restricting untrusted local shell access, limiting who can load or use BPF programs, disabling unprivileged BPF where operationally feasible, and applying standard kernel hardening controls. On many Linux distributions, unprivileged BPF can be restricted with kernel.unprivileged_bpf_disabled=1, subject to compatibility testing. Plan for reboot or live-patching validation as required by the platform, because kernel fixes generally are not fully effective until the running kernel is updated.

How to confirm the fix worked

Confirm the running kernel version is at or above the vendor-fixed version for the deployed distribution, not only that the package is installed. Validate with uname -r, package manager metadata, and vendor advisory mapping for this CVE. If live patching is used, confirm the relevant live patch is loaded and active. Review kernel logs after update or reboot to ensure there are no recurring general protection faults, KASAN null-ptr-deref reports, or stack traces referencing bpf_sk_storage_clone, bpf_sk_storage_diag_put_all, bpf_sk_storage_diag_put, or net/core/bpf_sk_storage.c. Where feasible in a staging environment, run representative BPF, socket, and connection-heavy workloads to confirm stability after patching.

Typical attack path

1. Identify a Linux system running a kernel build that contains the vulnerable BPF socket storage implementation.
2. Obtain local execution capability or another path to exercise BPF socket storage and high-volume socket lifecycle activity.
3. Create or manipulate BPF socket storage state associated with sockets.
4. Generate concurrent socket clone, connection handling, diagnostic, and teardown activity to race storage unlinking against RCU readers.
5. Trigger the NULL pointer dereference in bpf_sk_storage_clone() or bpf_sk_storage_diag_put_all().
6. Cause a kernel oops, panic, service disruption, or host reboot depending on kernel panic settings and workload resilience.

How to detect it

To determine whether this was already triggered, review historical kernel logs, system journals, crash dumps, hypervisor restart events, and monitoring alerts for kernel oops, panic, general protection fault, or KASAN reports involving BPF socket storage functions. Relevant log sources include dmesg, /var/log/kern.log, /var/log/messages, journalctl -k, crash dump infrastructure such as kdump/vmcore, endpoint telemetry that records kernel panics, and orchestration logs showing unexpected node reboots. Focus on stack traces containing bpf_sk_storage_clone, bpf_sk_storage_diag_put_all, bpf_sk_storage_diag_put, sk_clone, inet_csk_clone_lock, tcp_create_openreq_child, tcp_v4_syn_recv_sock, tcp_check_req, or tcp_v4_rcv. Also correlate any crash with bursts of local BPF activity, socket diagnostic tooling, high connection churn, container workload changes, or unexplained service/node restarts. These indicators show the vulnerable condition may have been hit, but they do not by themselves prove malicious exploitation because the bug can plausibly be triggered by benign race conditions or stress workloads.

• bpf_sk_storage_clone
• bpf_sk_storage_diag_put_all
• bpf_sk_storage_diag_put
• net/core/bpf_sk_storage.c
• bpf_selem_unlink_nofail
• KASAN: null-ptr-deref
• general protection fault, probably for non-canonical address
• RIP: 0010:bpf_sk_storage_clone
• sk_clone+
• inet_csk_clone_lock+
• tcp_create_openreq_child+
• tcp_v4_syn_recv_sock+
• tcp_check_req+
• tcp_v4_rcv+
• kernel NULL pointer dereference
• kernel panic - not syncing

What your security team should do

• Inventory Linux systems by running kernel version and distribution package level, prioritizing internet-facing servers, container hosts, Kubernetes nodes, load balancers, and multi-tenant compute platforms.
• Patch affected kernels using vendor-supplied fixed packages and schedule required reboots or live-patch activation as soon as operationally practical.
• If patching is delayed, restrict untrusted local access and disable or restrict unprivileged BPF where compatible with business workloads.
• Monitor kernel logs and centralized logging for crashes or oops reports referencing BPF socket storage functions.
• Treat unexplained host reboots, kernel panics, or repeated network-stack crashes on vulnerable kernels as potential exploitation or stress-triggered vulnerability events.
• Track vendor advisories for exact fixed versions because no product-specific fixed versions were supplied in the input.
• Do not over-prioritize ahead of known exploited remote code execution issues solely on exploit likelihood: current EPSS is low, exploit maturity is reported as none, and the issue is not in CISA KEV.