CVE-2026-52938

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Fix NULL pointer dereference in bpf_sk_storage_clone and diag paths<br /> <br /> bpf_selem_unlink_nofail() sets SDATA(selem)-&gt;smap to NULL before<br /> removing the selem from the storage hlist. A concurrent RCU reader in<br /> bpf_sk_storage_clone() can observe the selem still on the list with<br /> smap already NULL, causing a NULL pointer dereference.<br /> <br /> general protection fault, probably for non-canonical address 0xdffffc000000000a:<br /> KASAN: null-ptr-deref in range [0x0000000000000050-0x0000000000000057]<br /> RIP: 0010:bpf_sk_storage_clone+0x1cd/0xaa0 net/core/bpf_sk_storage.c:174<br /> Call Trace:<br /> <br /> sk_clone+0xfed/0x1980 net/core/sock.c:2591<br /> inet_csk_clone_lock+0x30/0x760 net/ipv4/inet_connection_sock.c:1222<br /> tcp_create_openreq_child+0x35/0x2680 net/ipv4/tcp_minisocks.c:571<br /> tcp_v4_syn_recv_sock+0x123/0xf90 net/ipv4/tcp_ipv4.c:1729<br /> tcp_check_req+0x8e1/0x2580 include/net/tcp.h:855<br /> tcp_v4_rcv+0x1845/0x3b80 net/ipv4/tcp_ipv4.c:2347<br /> <br /> Add a NULL check for smap in bpf_sk_storage_clone().<br /> <br /> bpf_sk_storage_diag_put_all() has the same issue. Add a NULL check<br /> and pass the validated smap directly to diag_get(), which is refactored<br /> to take smap as a parameter instead of reading it internally.<br /> <br /> bpf_sk_storage_diag_put() uses diag-&gt;maps[i] which is always valid<br /> under its refcount, so diag-&gt;maps[i] is passed directly to diag_get().