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.

Affected products

VendorProductVersions
LinuxLinuxfd09af010788a884de1c39537c288830c3d305db to <18e3ffde1822f0b48b1753bf34aa97ce839df1d8; fd09af010788a884de1c39537c288830c3d305db to <10f86a2a5c91fc4c4d001960f1c21abe52545ef6; 48be3df15aa19c04eadf156c9129293c9a10389f; cd4644d904e1d153d516e73e2e127e7a2fe687e1; 6e0bc946cbeec538322820786b5fb5200a2216ab; a7e52f7f675046d9ffc5692d815fa67c82fcdbf5; db7f8c57dbdd31f7e59f8dc8d1e1b38607a320ef; 5.7.18 to <5.8; 5.8.4 to <5.9; 5.4.61 to <5.5
LinuxLinux5.9; 0 to <5.9; 7.0.10 to <=7.0.*; 7.1 to <=*

References

Authoritative sources

This page is a snapshot. For the latest enrichment and updates, view the record on CVE.org or the NVD.

Generated from the official CVE List on 25 Jun 2026 10:14 UTC.