CVE-2026-53078: Linux Kernel Privilege Escalation Flaw

CVE-2026-53078 Overview

CVE-2026-53078 is a Linux kernel vulnerability in the Berkeley Packet Filter (BPF) sock_ops subsystem. The flaw resides in the SOCK_OPS_GET_SK() and SOCK_OPS_GET_FIELD() macros, which mishandle register allocation when dst_reg == src_reg. In the non-fullsock code path, the macros fail to zero the destination register, leaving a stale context pointer behind. Attackers running a crafted BPF sock_ops program can leverage this to trigger stack out-of-bounds reads through helpers such as bpf_skc_to_tcp6_sock() and to leak kernel pointers that the verifier treats as SCALAR_VALUE. The issue affects Linux kernels that include the vulnerable sock_ops context access macros.

Critical Impact
A local user able to load BPF sock_ops programs can read out-of-bounds kernel memory and leak kernel pointers, undermining kernel address space layout randomization (KASLR) and enabling further privilege escalation chains.

Affected Products

Linux kernel versions containing the vulnerable SOCK_OPS_GET_SK() and SOCK_OPS_GET_FIELD() macros
Distributions shipping affected upstream kernels prior to the referenced stable commits
Systems permitting unprivileged or container-scoped BPF program loading for sock_ops

Discovery Timeline

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

Technical Details for CVE-2026-53078

Vulnerability Analysis

The vulnerability lives in the BPF context rewrite logic that translates accesses to bpf_sock_ops fields into safe in-kernel instructions. When a BPF sock_ops program reads a context field, the verifier emits checks gated on is_fullsock and is_locked_tcp_sock. If these checks fail, for example during the TCP_NEW_SYN_RECV state with an attached request_sock, the destination register must be zeroed to prevent leaking the context pointer.

When the program uses the same register as both source and destination, the macros borrow a temporary register to perform the state check because the destination still holds the context pointer. The original code path failed to emit the zeroing instruction in the false branch. SOCK_OPS_GET_SK therefore returned the raw context pointer typed as PTR_TO_SOCKET_OR_NULL, which passes the verifier's NULL check and is then consumed by socket helpers as a bogus socket. SOCK_OPS_GET_FIELD left the context pointer in a register the verifier believed contained a scalar, exposing the kernel address to userspace.

Root Cause

The defect is an [CWE-125] out-of-bounds read combined with a kernel pointer disclosure caused by incorrect control flow in the context rewrite macros. The JMP_A(1) instruction in the fullsock path skipped one instruction, but the fix requires JMP_A(2) so the zeroing BPF_MOV64_IMM(si->dst_reg, 0) added in the non-fullsock path is bypassed when the socket is fully realized.

Attack Vector

Exploitation requires the ability to load a BPF sock_ops program, which on many distributions is gated by CAP_BPF or CAP_NET_ADMIN. An attacker writes a program that reads a bpf_sock_ops field into the same register that holds the context, triggers a code path where the socket is not fullsock, then feeds the stale pointer into a socket-typed helper. The result is an out-of-bounds read against kernel memory and, separately, disclosure of a kernel pointer treated as a scalar. The vulnerability mechanism is documented in the upstream commits at git.kernel.org commit 10f86a2a and git.kernel.org commit 18e3ffde.

Detection Methods for CVE-2026-53078

Indicators of Compromise

Unexpected loading of BPF sock_ops programs by non-system processes, visible through bpftool prog show enumeration.
Kernel log entries referencing crashes or KASAN reports in bpf_skc_to_tcp6_sock() or related socket cast helpers.
Userspace processes invoking bpf(BPF_PROG_LOAD) with prog_type == BPF_PROG_TYPE_SOCK_OPS outside of approved tooling.

Detection Strategies

Audit bpf() syscall activity with auditd rules targeting BPF_PROG_LOAD and correlate with the loading UID and container context.
Monitor for KASAN, UBSAN, or general protection fault traces in dmesg that originate from BPF socket helpers.
Inventory loaded BPF programs across hosts and alert on unsigned or unknown sock_ops programs.

Monitoring Recommendations

Forward kernel ring buffer and audit logs to a centralized analytics pipeline for retrospective hunting.
Track kernel version inventory against patched stable releases to flag unpatched hosts.
Alert on processes inside containers that acquire CAP_BPF or CAP_SYS_ADMIN unexpectedly.

How to Mitigate CVE-2026-53078

Immediate Actions Required

Apply the upstream stable kernel patches referenced in commits 10f86a2a and 18e3ffde as soon as your distribution vendor publishes builds.
Restrict CAP_BPF and CAP_NET_ADMIN to trusted system components and remove these capabilities from container workloads.
Set kernel.unprivileged_bpf_disabled=1 to prevent unprivileged users from loading BPF programs.

Patch Information

The upstream fix changes JMP_A(1) to JMP_A(2) in the fullsock path and inserts BPF_MOV64_IMM(si->dst_reg, 0) after the temporary register restore in the non-fullsock path. Both SOCK_OPS_GET_SK() and SOCK_OPS_GET_FIELD() are corrected. Patches are available at git.kernel.org commit 10f86a2a and git.kernel.org commit 18e3ffde. Consult your distribution's security tracker for backported package versions.

Workarounds

Disable unprivileged BPF program loading system-wide using sysctl -w kernel.unprivileged_bpf_disabled=1 and persist the setting in /etc/sysctl.d/.
Apply seccomp or Linux Security Module policies that block the bpf() syscall for untrusted workloads and container runtimes.
Drop CAP_BPF, CAP_NET_ADMIN, and CAP_SYS_ADMIN from container security contexts where BPF program loading is not required.

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 auditctl -a always,exit -F arch=b64 -S bpf -k bpf_syscall