CVE-2026-53078: bpf: Fix same-register dst/src OOB read and pointer leak in sock_ops
bpf: Fix same-register dst/src OOB read and pointer leak in sockops
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
Apply the resolved fix for the BPF sock_ops OOB read and pointer leak: in both SOCK_OPS_GET_FIELD and SOCK_OPS_GET_SK, ensure that when the corresponding check is false (e.g., !fullsock / !locked_tcp_sock paths), the destination register is zeroed even if dst_reg == src_reg, preventing a stale instruction from leaving a bogus ctx pointer that can leak kernel pointers.
Linux kernel BPF sock_ops (macros SOCK_OPS_GET_FIELD / SOCK_OPS_GET_SK) Fix same-register dst/src handling = Zero dst_reg when dst_reg == src_reg and fullsock/locked checks fail - Configuration
In the fullsock path, change JMP_A(1) to JMP_A(2) so the verifier skips the problematic section that can lead to stack-out-of-bounds access when dst_reg == src_reg.
Linux kernel BPF sock_ops (fullsock path in SOCK_OPS_GET_SK macro) Jump target after fullsock check = Change JMP_A(1) to JMP_A(2) - Configuration
Fix both macros by inserting BPF_MOV64_IMM(si->dst_reg, 0) after the temporary register use, so dst_reg is explicitly zeroed when the check is false and dst_reg==src_reg would otherwise retain the ctx pointer.
Linux kernel BPF sock_ops (temp register handling in SOCK_OPS_GET_SK / SOCK_OPS_GET_FIELD) BPF_MOV64_IMM after temp register = Add BPF_MOV64_IMM(si->dst_reg, 0) after the temp register
Event History
Frequently Asked Questions
What access does an attacker need?
The severity vector indicates local access, low privileges, and no user interaction are required. Exploitation also depends on a BPF sock_ops program reaching the affected context-field access path.
When is the vulnerable path reached?
The issue occurs when a BPF sock_ops program accesses context fields with the destination and source registers being the same, and the socket is not a full socket or not a locked TCP socket. An example cited is TCP_NEW_SYN_RECV with a request_sock.
What can exploitation lead to?
A stale context pointer can be treated as a socket pointer and trigger stack out-of-bounds access in helpers such as bpf_skc_to_tcp6_sock(). The stale pointer may also be treated as a scalar value, allowing a kernel-pointer leak.
How can I determine whether the issue is fixed?
No affected version range is provided. Verify that the kernel includes the described sock_ops macro changes: the adjusted fullsock jump and explicit zeroing of the destination register in the non-fullsock path, or confirm that it incorporates one of the referenced stable fixes.