Description
In the Linux kernel, the following vulnerability has been resolved:

bpf: Fix same-register dst/src OOB read and pointer leak in sock_ops

When a BPF sock_ops program accesses ctx fields with dst_reg == src_reg,
the SOCK_OPS_GET_SK() and SOCK_OPS_GET_FIELD() macros fail to zero the
destination register in the !fullsock / !locked_tcp_sock path.

Both macros borrow a temporary register to check is_fullsock /
is_locked_tcp_sock when dst_reg == src_reg, because dst_reg holds the
ctx pointer. When the check is false (e.g., TCP_NEW_SYN_RECV state with
a request_sock), dst_reg should be zeroed but is not, leaving the stale
ctx pointer:

- SOCK_OPS_GET_SK: dst_reg retains the ctx pointer, passes NULL checks
as PTR_TO_SOCKET_OR_NULL, and can be used as a bogus socket pointer,
leading to stack-out-of-bounds access in helpers like
bpf_skc_to_tcp6_sock().

- SOCK_OPS_GET_FIELD: dst_reg retains the ctx pointer which the
verifier believes is a SCALAR_VALUE, leaking a kernel pointer.

Fix both macros by:
- Changing JMP_A(1) to JMP_A(2) in the fullsock path to skip the
added instruction.
- Adding BPF_MOV64_IMM(si->dst_reg, 0) after the temp register
restore in the !fullsock path, placed after the restore because
dst_reg == src_reg means we need src_reg intact to read ctx->temp.
Published: 2026-06-24
Score: n/a
EPSS: n/a
KEV: No
Impact: n/a
Action: n/a
AI Analysis

Impact

In Linux kernel BPF sock_ops programs, when the destination and source registers are the same, the macros SOCK_OPS_GET_SK() and SOCK_OPS_GET_FIELD() incorrectly leave the destination register unchanged after a failed full socket check. This stale ctx pointer can be treated as a socket pointer and exploited for a stack-out-of-bounds access, or it can be exposed to the verifier as a scalar value, leaking a kernel address. The vulnerability allows an attacker who can inject BPF programs to obtain kernel memory pointers and potentially cause memory corruption or privilege escalation.

Affected Systems

All Linux kernel versions before the patch commit 10f86a2a5c91fc4c4d001960f1c21abe52545ef6 and 18e3ffde1822f0b48b1753bf34aa97ce839df1d8 are impacted; users should apply any kernel updates that incorporate these patches.

Risk and Exploitability

The CVSS score is not provided, and EPSS is unavailable, so the exploitation probability cannot be quantified precisely. The vulnerability is not listed in CISA KEV. Exploitation requires the ability to load BPF sock_ops programs, meaning the attacker must have sufficient privileges (CAP_SYS_ADMIN or equivalent). Therefore the risk is moderate: trusted users could exploit the flaw, but it is not trivially available to an unauthenticated attacker.

Generated by OpenCVE AI on June 24, 2026 at 19:15 UTC.

Remediation

No vendor fix or workaround currently provided.

OpenCVE Recommended Actions

  • Apply the latest Linux kernel update that includes the fix committed in https://git.kernel.org/stable/c/10f86a2a5c91fc4c4d001960f1c21abe52545ef6 and https://git.kernel.org/stable/c/18e3ffde1822f0b48b1753bf34aa97ce839df1d8
  • If a kernel upgrade cannot be applied immediately, restrict the ability to load BPF sock_ops programs to trusted system components by limiting CAP_SYS_ADMIN or using role‑based access control
  • After applying the update or restriction, reboot the system to ensure the fixed kernel code is active

Generated by OpenCVE AI on June 24, 2026 at 19:15 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

Wed, 24 Jun 2026 19:45:00 +0000

Type Values Removed Values Added
Weaknesses CWE-126
CWE-200

Wed, 24 Jun 2026 17:15:00 +0000

Type Values Removed Values Added
Description In the Linux kernel, the following vulnerability has been resolved: bpf: Fix same-register dst/src OOB read and pointer leak in sock_ops When a BPF sock_ops program accesses ctx fields with dst_reg == src_reg, the SOCK_OPS_GET_SK() and SOCK_OPS_GET_FIELD() macros fail to zero the destination register in the !fullsock / !locked_tcp_sock path. Both macros borrow a temporary register to check is_fullsock / is_locked_tcp_sock when dst_reg == src_reg, because dst_reg holds the ctx pointer. When the check is false (e.g., TCP_NEW_SYN_RECV state with a request_sock), dst_reg should be zeroed but is not, leaving the stale ctx pointer: - SOCK_OPS_GET_SK: dst_reg retains the ctx pointer, passes NULL checks as PTR_TO_SOCKET_OR_NULL, and can be used as a bogus socket pointer, leading to stack-out-of-bounds access in helpers like bpf_skc_to_tcp6_sock(). - SOCK_OPS_GET_FIELD: dst_reg retains the ctx pointer which the verifier believes is a SCALAR_VALUE, leaking a kernel pointer. Fix both macros by: - Changing JMP_A(1) to JMP_A(2) in the fullsock path to skip the added instruction. - Adding BPF_MOV64_IMM(si->dst_reg, 0) after the temp register restore in the !fullsock path, placed after the restore because dst_reg == src_reg means we need src_reg intact to read ctx->temp.
Title bpf: Fix same-register dst/src OOB read and pointer leak in sock_ops
First Time appeared Linux
Linux linux Kernel
CPEs cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Vendors & Products Linux
Linux linux Kernel
References

Subscriptions

Linux Linux Kernel
cve-icon MITRE

Status: PUBLISHED

Assigner: Linux

Published:

Updated: 2026-06-24T16:30:18.858Z

Reserved: 2026-06-09T07:44:35.383Z

Link: CVE-2026-53078

cve-icon Vulnrichment

No data.

cve-icon NVD

No data.

cve-icon Redhat

No data.

cve-icon OpenCVE Enrichment

Updated: 2026-06-24T19:30:08Z

Weaknesses
  • CWE-126

    Buffer Over-read

  • CWE-200

    Exposure of Sensitive Information to an Unauthorized Actor