CVE-2026-53078

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