CVE-2026-43016

What it actually does

This is a Linux kernel use-after-free in the BPF sockmap/sk_psock path. A local attacker can trigger a race involving AF_UNIX stream sockets, sockmap verdict handling, and socket orphaning so that sk_psock_verdict_data_ready() dereferences a freed sk->sk_socket pointer. Because the bug is in kernel memory handling, successful exploitation may lead to kernel memory corruption, system crash, or potentially local privilege escalation with kernel-level code execution, depending on exploit reliability and available hardening. Exploitation is local and requires low privileges, but practical reachability may depend on whether the attacker can use the relevant eBPF/BPF sockmap functionality, which is often restricted by CAP_BPF, CAP_NET_ADMIN, CAP_SYS_ADMIN, or the unprivileged BPF sysctl on hardened systems.

Why it matters to the business

A successful attack could allow a local user, compromised application, or containerized workload with sufficient kernel/BPF access to crash the host or gain elevated privileges on the underlying system. For multi-user Linux servers, container platforms, CI runners, and systems that permit unprivileged or broadly delegated BPF use, the operational risk is higher because compromise of a low-privileged process could become full host compromise. The vulnerability is not listed in CISA KEV, is not known to be used in ransomware campaigns, has very low EPSS, and has no known public exploit maturity in the provided data, so urgency should be driven primarily by kernel exposure, BPF policy, and the sensitivity of workloads rather than evidence of active widespread exploitation.

How an attack unfolds

An attacker first obtains local code execution as a low-privileged user or within a workload that can reach the necessary BPF sockmap functionality. They create AF_UNIX stream sockets, attach or interact with BPF sockmap/sk_psock verdict processing, and then manipulate socket lifetime by causing the peer socket to be orphaned or freed while another path still invokes sk_data_ready during unix_stream_sendmsg(). In the vulnerable kernel, sk_psock_verdict_data_ready() can read sk->sk_socket after it has been freed following an RCU grace period. An attacker then attempts to turn this stale pointer dereference into a controlled kernel memory corruption primitive. Less sophisticated attempts are likely to produce kernel warnings, KASAN reports, oopses, or host crashes; a reliable exploit could potentially escalate privileges to root or escape a container by executing code in kernel context.

How to fix it

Apply the Linux kernel update from the relevant distribution or kernel vendor that includes the fix for the BPF sockmap sk->sk_socket use-after-free in sk_psock_verdict_data_ready(). No exact fixed package versions were provided in the input, so track vendor advisories for the deployed kernel branches and upgrade to the first fixed kernel release or later. Because kernel updates normally require booting into the new kernel, schedule and verify a reboot after patch installation. As interim risk reduction, disable unprivileged BPF where operationally possible using kernel.unprivileged_bpf_disabled=1 or the vendor-supported equivalent, restrict CAP_BPF, CAP_NET_ADMIN, and CAP_SYS_ADMIN to only trusted workloads, avoid granting privileged containers unnecessary host capabilities, and use seccomp/AppArmor/SELinux/container runtime policy to reduce access to bpf(), socketpair(), and related high-risk kernel interfaces for untrusted code. These mitigations reduce exploitability but do not replace applying the kernel fix.

How to confirm the fix worked

Confirm the running kernel, not just the installed package, is fixed. Check uname -a and the distribution package metadata after reboot, then compare the running kernel build against the vendor advisory for this vulnerability. Validate that vulnerable older kernels are not still available as the default boot entry. Where source or build metadata is available, confirm the kernel contains the sockmap fix that fetches sk->sk_socket and socket ops under RCU in sk_psock_verdict_data_ready(). Verify mitigation posture by checking sysctl kernel.unprivileged_bpf_disabled, reviewing which workloads receive CAP_BPF, CAP_NET_ADMIN, CAP_SYS_ADMIN, or privileged-container status, and using bpftool to inventory loaded BPF programs and SOCKMAP/SOCKHASH maps. A negative vulnerability scanner result should be treated as valid only if it inspects the running kernel version and vendor backport status.

Typical attack path

1. Gain local execution on a Linux system as an unprivileged user, compromised service account, or containerized process.
2. Determine whether BPF sockmap functionality is usable, either through unprivileged BPF or delegated capabilities such as CAP_BPF, CAP_NET_ADMIN, or CAP_SYS_ADMIN.
3. Create AF_UNIX stream socket pairs and BPF sockmap or related sk_psock state needed to invoke verdict data-ready handling.
4. Race socket send operations against peer socket teardown/orphaning so sk->sk_socket is freed while sk_psock_verdict_data_ready() can still access it.
5. Trigger the use-after-free through sendmsg()/unix_stream_sendmsg() and repeat to improve reliability.
6. Exploit resulting kernel memory corruption to crash the host or attempt privilege escalation to kernel/root privileges.

How to detect it

Look for evidence of attempted or successful local exploitation in kernel logs, audit logs, endpoint telemetry, and BPF inventory. Primary artifacts are kernel oops, panic, KASAN, or slab-use-after-free reports referencing sk_psock_verdict_data_ready(), net/core/skmsg.c, unix_stream_sendmsg(), or AF_UNIX socket send paths. On production kernels without KASAN, exploitation attempts may appear only as unexplained kernel panics, soft lockups, general protection faults, or sudden reboots. In auditd or syscall telemetry, investigate non-administrative processes invoking bpf() to create SOCKMAP or SOCKHASH maps, loading socket-related BPF programs, and rapidly exercising socketpair() and sendmsg() around the time of a crash. Use bpftool or equivalent telemetry to identify unexpected BPF programs and maps, especially BPF_MAP_TYPE_SOCKMAP or BPF_MAP_TYPE_SOCKHASH owned by unusual processes or containers. Because there are no known public exploit indicators in the provided data, detection should focus on behavioral and crash artifacts rather than fixed network IOCs.

• sk_psock_verdict_data_ready
• BUG: KASAN: slab-use-after-free in sk_psock_verdict_data_ready
• slab-use-after-free in sk_psock_verdict_data_ready
• net/core/skmsg.c:1278
• unix_stream_sendmsg
• net/unix/af_unix.c:2482
• __x64_sys_sendmsg
• __x64_sys_socketpair
• BPF_MAP_TYPE_SOCKMAP
• BPF_MAP_TYPE_SOCKHASH
• map_type=SOCKMAP
• map_type=SOCKHASH
• kernel.unprivileged_bpf_disabled=0
• general protection fault in sk_psock_verdict_data_ready
• kernel panic - not syncing
• Oops:

What your security team should do

• Prioritize patching internet-facing, multi-tenant, container-hosting, CI/CD, developer workstation, and shared Linux systems where untrusted local code can run.
• Inventory Linux kernel versions across the fleet and map them to vendor advisories; because no fixed versions were provided, rely on distribution backport notices rather than upstream version numbers alone.
• Disable or restrict unprivileged BPF and review all workloads granted CAP_BPF, CAP_NET_ADMIN, CAP_SYS_ADMIN, or privileged-container access.
• Reboot systems after kernel update and confirm the running kernel is the fixed build.
• Hunt for recent kernel crashes, KASAN reports, oopses, or suspicious BPF sockmap activity, especially on hosts running untrusted workloads.
• Add audit or eBPF-based monitoring for unusual bpf() syscall activity, creation of SOCKMAP/SOCKHASH maps, and unexpected BPF program loads by non-administrative processes.
• For container platforms, review runtime profiles to prevent unnecessary host namespace sharing and capability delegation.
• Treat unexplained local privilege escalation, container escape, or repeated kernel panics on affected kernels as potentially related until ruled out.