CVE Watch19 oct 2026

CVE-2026-53078

In the Linux kernel, the following vulnerability has been resolved: bpf: Fix same-register dst/src OOB read and pointer leak in sock_ops W

CVSS

7.8

Alto

EPSS

0.1%

KEV

—

Exploit Today

0-100

Publicado: 24 jun 2026 · Última mod.: 19 oct 2026 · CWE-125

EPSS · 30d

0.1%EPSS · 30 días0.2%

2026-10-052026-11-02

Descripción técnica

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.

Referencias oficiales

CVEs relacionados

CVECVSSEPSSKEVRExplotTítuloVis.

CVE-2026-1216043.3 BAJ

—

———wlroots before 0.20.2 contains an out-of-bounds read vulnerability in read_surface_class() in xwayland/xwm.c that allows local X11 clients to leak compositor heap memory. Attackers can set a WM_CLASS property with a NUL-terminated instance but unterminated class, exposing over-read heap bytes as the window class or app_id over IPC.1h CVE-2026-651386.3 MED

—

———NVIDIA Slurm contains an attacker-controlled arbitrary-memory read in the slurmstepd socket API that could be used to ex-filtrate authentication keys.2h CVE-2026-120757—

—

———HDF5 through 2.2.0 contains a heap buffer over-read vulnerability in H5L__extern_traverse() in src/H5Lexternal.c, the default traversal callback for external links. The callback locates the target file name and object path within the link’s user data using strlen() without validating the buffer against its stored size (udata_size, which was marked unused). A crafted HDF5 file containing an external link whose data is not NULL-terminated, or is too short to hold both strings, causes strlen() to read past the end of the udata heap buffer, and the derived object path pointer may also point outside the buffer. The overrun is unbounded and continues until a zero byte is found. The flaw is triggered when the malicious link is traversed, for example when opening an object through it. An attacker who can get a user or application to access a crafted file can cause a denial of service, and adjacent heap contents may be incorporated into the external file name or object path the library attempts to open.2h CVE-2026-120756—

—

———HDF5 through 2.2.0 contains a heap buffer over-read vulnerability in H5O__chunk_deserialize() in src/H5Ocache.c. When decoding object header messages, the declared message size is checked against the end of the chunk image before the remainder of the message header (flags, and for version 2 object headers, the optional creation index) has been decoded. Because the message body begins after these fields, a message can start up to four bytes further into the chunk than the size check accounts for. A crafted HDF5 file can declare a message size that passes the check but extends past the end of the chunk image, causing the message’s decode callback, for example H5O__mtime_new_decode() in src/H5Omtime.c, to read beyond the heap allocation. The flaw is reachable during H5Fopen() on a crafted file. An attacker who can get a user or application to open a malicious file can cause a denial of service or limited disclosure of process memory.2h CVE-2026-120755—

—

———HDF5 through 2.2.0 contains an out-of-bounds read vulnerability in H5Z__filter_szip() in src/H5Zszip.c. When decoding a szip-compressed chunk, the function subtracts the 4-byte uncompressed-length header from the chunk length without first verifying that the chunk is at least 4 bytes long. A truncated or corrupted chunk shorter than the header causes the length calculation to wrap around to a very large value, and the decompressor reads far past the end of the chunk buffer. An attacker who can get a user or application to read a dataset from a crafted HDF5 file can cause a denial of service. Only builds with szip support (libaec or the szip library) are affected.2h CVE-2026-40660—

—

———A heap-based out-of-bounds (OOB) read vulnerability in the AMD Compressonator SDK could allow an attacker with local access to read out-of-bounds heap memory, potentially resulting in information disclosure or application crash.2h