CVE-2026-53078

What it actually does

This Linux kernel flaw affects BPF sock_ops program handling when a generated field access uses the same BPF register as both source and destination. In specific non-full socket or unlocked TCP socket paths, such as TCP_NEW_SYN_RECV/request_sock handling, kernel BPF helper expansion fails to clear the destination register. As a result, a stale sock_ops context pointer may remain in a register that the verifier believes is either a nullable socket pointer or a scalar value. Depending on the access pattern, this can produce a bogus socket pointer usable by helpers such as bpf_skc_to_tcp6_sock(), causing stack out-of-bounds reads, or expose a kernel pointer value to the BPF program. The primary impact is kernel memory information disclosure and pointer leakage, with possible value as a primitive for bypassing kernel address-space randomization or supporting a broader local privilege-escalation chain.

Why it matters to the business

Successful exploitation could allow an attacker who can load and attach BPF sock_ops programs to extract sensitive kernel memory or kernel pointer values from affected Linux systems. By itself this is an information-disclosure issue, but kernel pointer leaks are often used to make other kernel exploits more reliable. Systems that permit unprivileged BPF use, containerized workloads with elevated BPF-related capabilities, or hosts where users can attach cgroup sock_ops programs have higher operational risk. No CISA KEV listing, ransomware association, public exploit maturity, or high EPSS signal is indicated in the supplied data, so broad active exploitation is not currently evidenced; however, kernel/BPF bugs should still be prioritized on multi-user, container-hosting, and internet-facing infrastructure because they can become useful exploit-chain components.

How an attack unfolds

An attacker first needs local code execution with sufficient permission to create and attach a BPF sock_ops program, typically through CAP_BPF, CAP_SYS_ADMIN, a permissive unprivileged BPF configuration, or a container/namespace configuration that exposes those capabilities. The attacker then crafts a sock_ops BPF program whose generated access pattern causes the same register to be used as both the source context register and destination register. The program targets a socket state where the fullsock or locked_tcp_sock check fails, such as request_sock handling during TCP_NEW_SYN_RECV. In the vulnerable kernel path, the macro restores the temporary register but does not zero the destination register, leaving a stale ctx pointer. The verifier’s model no longer matches the actual register contents: in one path the stale pointer is treated like a nullable socket pointer and may be supplied to socket conversion helpers, while in another it is treated as a scalar and can be leaked. The attacker observes leaked pointer or memory values through normal BPF output channels such as maps, perf/ring buffers, or program return-side effects, and may then use the disclosure to defeat kernel address randomization or prepare a separate kernel exploit.

How to fix it

Apply a Linux kernel update that includes the upstream fix for the BPF sock_ops same-register handling issue. The fix zeroes the destination register in the non-fullsock path and corrects the jump behavior so stale context pointers are not retained. Because no exact affected product list or package fixed versions were supplied, use vendor advisories for the deployed distribution or kernel source tree to identify the first fixed kernel build. As interim risk reduction, disable unprivileged BPF where operationally feasible by setting kernel.unprivileged_bpf_disabled=1 or the distribution equivalent, restrict CAP_BPF and CAP_SYS_ADMIN to trusted workloads only, avoid granting broad BPF capability to containers, restrict cgroup BPF attachment to administrators, and use LSM/seccomp/container policy to prevent untrusted processes from invoking bpf() where possible. These mitigations reduce exploitability but do not replace a kernel fix.

How to confirm the fix worked

Confirm the running kernel build includes the vendor backport or upstream commit that fixes BPF sock_ops same-register dst/src handling. Validate with the distribution’s package metadata and security advisory rather than relying only on the upstream version number, because kernel fixes are commonly backported. Check runtime exposure by confirming unprivileged BPF is disabled where expected, reviewing whether untrusted users or containers have CAP_BPF, CAP_SYS_ADMIN, or permissions to attach cgroup sock_ops programs, and testing that policy blocks unauthorized bpf() program loads. After patching, reboot into the fixed kernel and verify with uname/package inventory that the active kernel, not merely the installed package, is fixed. In controlled test environments, a regression proof-of-concept should fail to leak kernel pointers or be rejected/neutralized; do not run exploit code on production systems.

Typical attack path

1. Obtain local execution on an affected Linux system.
2. Gain or abuse the ability to load and attach BPF sock_ops programs, such as CAP_BPF, CAP_SYS_ADMIN, permissive unprivileged BPF, or exposed container capabilities.
3. Create a cgroup/socket environment where a sock_ops program can run against relevant TCP connection states, including non-full socket/request_sock paths.
4. Load a crafted BPF sock_ops program that forces same-register source/destination field access.
5. Trigger TCP events that cause the vulnerable fullsock or locked_tcp_sock check to take the false path.
6. Use the stale register contents to disclose a kernel pointer or drive an out-of-bounds read through affected helper behavior.
7. Recover leaked values through BPF maps, ring buffers, perf buffers, or other program-visible output mechanisms.
8. Optionally combine the leak with another vulnerability to improve reliability of kernel code execution or privilege escalation.

How to detect it

To determine whether this was already exploited, review host telemetry for BPF program load and attach activity around the suspected exposure window. Useful sources include auditd syscall logs for bpf(), Linux security module denials, eBPF management telemetry, bpftool output/history where available, EDR process telemetry, shell history for administrative users, container runtime audit logs, and Kubernetes/node audit records showing privileged containers or added CAP_BPF/CAP_SYS_ADMIN. Focus on BPF_PROG_TYPE_SOCK_OPS programs, BPF_PROG_LOAD, BPF_PROG_ATTACH, and cgroup sock_ops attachments created by unexpected users or processes. Inspect pinned BPF objects under bpffs, loaded BPF program lists, and BPF maps for unfamiliar entries, especially programs referencing socket conversion helpers or exporting values through maps/ring buffers. Kernel logs may not show a reliable crash or warning because the exploit objective is disclosure, not necessarily instability. Look for suspicious sequences of local code execution followed by BPF loading, TCP connection triggering, and reading BPF maps or perf/ring buffers. Because this vulnerability may only leave generic BPF artifacts, absence of logs is not proof of non-exploitation; preserve volatile state with bpftool before rebooting when compromise is suspected.

• BPF_PROG_TYPE_SOCK_OPS
• BPF_PROG_LOAD
• BPF_PROG_ATTACH
• BPF_CGROUP_SOCK_OPS
• bpf_skc_to_tcp6_sock
• /sys/fs/bpf/
• kernel.unprivileged_bpf_disabled=0
• cap_bpf
• CAP_BPF
• cap_sys_admin
• CAP_SYS_ADMIN
• bpftool prog show
• bpftool cgroup tree
• bpftool map dump
• syscall=bpf
• BPF_MAP_LOOKUP_ELEM
• BPF_MAP_UPDATE_ELEM

What your security team should do

• Prioritize patching shared Linux hosts, container platforms, Kubernetes nodes, CI runners, and multi-user systems where untrusted code may execute.
• Immediately inventory systems that allow BPF program loading, cgroup BPF attachment, CAP_BPF, CAP_SYS_ADMIN, or unprivileged BPF.
• Disable unprivileged BPF unless there is a documented business requirement; verify the setting persists across reboot.
• Remove CAP_BPF and CAP_SYS_ADMIN from containers and service accounts that do not explicitly require them.
• Monitor for unusual BPF program load and attach activity, especially BPF_PROG_TYPE_SOCK_OPS programs attached to cgroups by unexpected users or processes.
• Treat detected kernel pointer leaks or suspicious BPF sock_ops activity as potential staging for a larger local privilege-escalation attempt.
• Track vendor kernel advisories for fixed package versions and ensure systems are rebooted into the remediated kernel after installation.