Skip to main content

Linux Kernel CVE-2026-53078

| EUVDEUVD-2026-38946 HIGH
Out-of-bounds Read (CWE-125)
2026-06-24 Linux GHSA-pwr6-cvf5-35f3
7.8
CVSS 3.1 · Vendor: Linux
Share

Severity by source

Vendor (Linux) PRIMARY
7.8 HIGH
AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
vuln.today AI
7.3 HIGH

Local attacker needs BPF-load privilege (PR:L, AV:L) with a reliable trigger (AC:L); strong kernel-pointer/OOB info leak (C:H) and crash potential (A:H), with limited demonstrated write impact (I:L).

3.1 AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:H
4.0 AV:L/AC:L/AT:N/PR:L/UI:N/VC:H/VI:L/VA:H/SC:N/SI:N/SA:N
SUSE
6.7 MEDIUM
AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H
Red Hat
7.0 MEDIUM
qualitative

Primary rating from Vendor (Linux).

CVSS VectorVendor: Linux

Attack Vector
Local
Attack Complexity
Low
Privileges Required
Low
User Interaction
None
Scope
Unchanged
Confidentiality
High
Integrity
High
Availability
High

Lifecycle Timeline

5
Analysis Generated
Jun 28, 2026 - 09:06 vuln.today
CVSS changed
Jun 28, 2026 - 08:22 NVD
7.8 (HIGH)
Patch available
Jun 24, 2026 - 18:02 EUVD
CVE Published
Jun 24, 2026 - 16:30 cve.org
UNKNOWN (no severity yet)
CVE Published
Jun 24, 2026 - 16:30 cve.org
HIGH 7.8

DescriptionCVE.org

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.

AnalysisAI

Out-of-bounds read and kernel pointer leak in the Linux kernel's eBPF sock_ops subsystem lets a local low-privileged actor able to load BPF programs disclose kernel memory and corrupt kernel state. The SOCK_OPS_GET_SK() and SOCK_OPS_GET_FIELD() macros fail to zero the destination register on the !fullsock/!locked_tcp_sock path when dst_reg == src_reg, leaving a stale ctx pointer that the verifier mistakes for a valid socket or a scalar. There is no public exploit identified at time of analysis, and EPSS exploitation probability is low (0.14%, 4th percentile).

Technical ContextAI

The flaw lives in the kernel's eBPF (Berkeley Packet Filter) socket-operations program type (BPF_PROG_TYPE_SOCK_OPS), which lets BPF programs read TCP socket context fields during connection-lifecycle events. The macros SOCK_OPS_GET_SK and SOCK_OPS_GET_FIELD borrow a temporary register to test is_fullsock / is_locked_tcp_sock when dst_reg and src_reg are the same register (because that register currently holds the ctx pointer). On the false branch - reached for example in the TCP_NEW_SYN_RECV state where the socket is only a request_sock - the destination register should be cleared to NULL but is not, so it retains the ctx pointer. For SOCK_OPS_GET_SK this stale value survives NULL checks as PTR_TO_SOCKET_OR_NULL and is consumed as a bogus socket pointer by helpers such as bpf_skc_to_tcp6_sock(), yielding stack-out-of-bounds access; for SOCK_OPS_GET_FIELD the verifier treats it as a SCALAR_VALUE, directly leaking a raw kernel pointer. The root-cause class is an out-of-bounds read (CWE-125) compounded by information exposure / pointer leak (CWE-200); the NVD CWE field is listed as N/A. Affected products are identified by the CPE strings cpe:2.3:a:linux:linux:*, i.e. the mainline Linux kernel.

RemediationAI

Upstream fix available (commit); the released patched kernel version is not independently confirmed beyond the stable git commits, so apply your distribution's updated kernel package once it incorporates stable commits 18e3ffde1822f0b48b1753bf34aa97ce839df1d8 and 10f86a2a5c91fc4c4d001960f1c21abe52545ef6 (see https://git.kernel.org/stable/c/18e3ffde1822f0b48b1753bf34aa97ce839df1d8 and https://git.kernel.org/stable/c/10f86a2a5c91fc4c4d001960f1c21abe52545ef6). The fix zeroes the destination register on the !fullsock path and adjusts the jump offset (JMP_A(1) to JMP_A(2)). Where you cannot patch immediately, the most effective compensating control is to deny loading of sock_ops BPF programs by setting kernel.unprivileged_bpf_disabled=1 (sysctl) so only capability-holding processes can load BPF - side effect: legitimate unprivileged BPF tools break. Further restrict or drop CAP_BPF and CAP_NET_ADMIN from untrusted workloads and containers (side effect: networking/observability agents relying on these caps lose functionality), and avoid running untrusted BPF on multi-tenant hosts. These controls reduce exposure but do not remove the underlying bug, so schedule the kernel update.

Vendor StatusVendor

SUSE

Severity: Moderate
Product Status
Container suse/sl-micro/6.0/base-os-container:2.1.3-7.177 Container suse/sl-micro/6.1/base-os-container:2.2.1-5.155 Affected
Container suse/sl-micro/6.0/rt-os-container:2.1.3-7.206 Container suse/sl-micro/6.1/rt-os-container:2.2.1-5.152 Affected
Image SLES15-SP7-Azure-3P Image SLES15-SP7-Azure-Basic Image SLES15-SP7-Azure-Standard Image SLES15-SP7-HPC-Azure Affected
Image SLES15-SP7-BYOS-Azure Image SLES15-SP7-BYOS-GCE Image SLES15-SP7-CHOST-BYOS-Aliyun Image SLES15-SP7-CHOST-BYOS-Azure Image SLES15-SP7-CHOST-BYOS-EC2 Image SLES15-SP7-CHOST-BYOS-GCE Image SLES15-SP7-CHOST-BYOS-GDC Image SLES15-SP7-CHOST-BYOS-SAP-CCloud Image SLES15-SP7-EC2 Image SLES15-SP7-EC2-ECS-HVM Image SLES15-SP7-GCE Image SLES15-SP7-HPC-BYOS-Azure Image SLES15-SP7-HPC-BYOS-EC2 Image SLES15-SP7-HPC-BYOS-GCE Image SLES15-SP7-Hardened-BYOS-Azure Image SLES15-SP7-Hardened-BYOS-EC2 Image SLES15-SP7-Hardened-BYOS-GCE Image SLES15-SP7-SAPCAL-Azure Image SLES15-SP7-SAPCAL-EC2 Image SLES15-SP7-SAPCAL-GCE Affected
Image SLES15-SP7-SAP-Azure Image SLES15-SP7-SAP-Azure-3P Image SLES15-SP7-SAP-BYOS-Azure Image SLES15-SP7-SAP-BYOS-EC2 Image SLES15-SP7-SAP-BYOS-GCE Image SLES15-SP7-SAP-EC2 Image SLES15-SP7-SAP-GCE Image SLES15-SP7-SAP-Hardened-Azure Image SLES15-SP7-SAP-Hardened-BYOS-Azure Image SLES15-SP7-SAP-Hardened-BYOS-EC2 Image SLES15-SP7-SAP-Hardened-BYOS-GCE Image SLES15-SP7-SAP-Hardened-GCE Affected

Share

CVE-2026-53078 vulnerability details – vuln.today

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy