CVE-2026-53034

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf, sockmap: Fix af_unix null-ptr-deref in proto update<br /> <br /> unix_stream_connect() sets sk_state (`WRITE_ONCE(sk-&gt;sk_state,<br /> TCP_ESTABLISHED)`) _before_ it assigns a peer (`unix_peer(sk) = newsk`).<br /> sk_state == TCP_ESTABLISHED makes sock_map_sk_state_allowed() believe that<br /> socket is properly set up, which would include having a defined peer. IOW,<br /> there&amp;#39;s a window when unix_stream_bpf_update_proto() can be called on<br /> socket which still has unix_peer(sk) == NULL.<br /> <br /> CPU0 bpf CPU1 connect<br /> -------- ------------<br /> <br /> WRITE_ONCE(sk-&gt;sk_state, TCP_ESTABLISHED)<br /> sock_map_sk_state_allowed(sk)<br /> ...<br /> sk_pair = unix_peer(sk)<br /> sock_hold(sk_pair)<br /> sock_hold(newsk)<br /> smp_mb__after_atomic()<br /> unix_peer(sk) = newsk<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000080<br /> RIP: 0010:unix_stream_bpf_update_proto+0xa0/0x1b0<br /> Call Trace:<br /> sock_map_link+0x564/0x8b0<br /> sock_map_update_common+0x6e/0x340<br /> sock_map_update_elem_sys+0x17d/0x240<br /> __sys_bpf+0x26db/0x3250<br /> __x64_sys_bpf+0x21/0x30<br /> do_syscall_64+0x6b/0x3a0<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> <br /> Initial idea was to move peer assignment _before_ the sk_state update[1],<br /> but that involved an additional memory barrier, and changing the hot path<br /> was rejected.<br /> Then a NULL check during proto update in unix_stream_bpf_update_proto() was<br /> considered[2], but the follow-up discussion[3] focused on the root cause,<br /> i.e. sockmap update taking a wrong lock. Or, more specifically, missing<br /> unix_state_lock()[4].<br /> In the end it was concluded that teaching sockmap about the af_unix locking<br /> would be unnecessarily complex[5].<br /> Complexity aside, since BPF_PROG_TYPE_SCHED_CLS and BPF_PROG_TYPE_SCHED_ACT<br /> are allowed to update sockmaps, sock_map_update_elem() taking the unix<br /> lock, as it is currently implemented in unix_state_lock():<br /> spin_lock(&amp;unix_sk(s)-&gt;lock), would be problematic. unix_state_lock() taken<br /> in a process context, followed by a softirq-context TC BPF program<br /> attempting to take the same spinlock -- deadlock[6].<br /> This way we circled back to the peer check idea[2].<br /> <br /> [1]: https://lore.kernel.org/netdev/ba5c50aa-1df4-40c2-ab33-a72022c5a32e@rbox.co/<br /> [2]: https://lore.kernel.org/netdev/20240610174906.32921-1-kuniyu@amazon.com/<br /> [3]: https://lore.kernel.org/netdev/7603c0e6-cd5b-452b-b710-73b64bd9de26@linux.dev/<br /> [4]: https://lore.kernel.org/netdev/CAAVpQUA+8GL_j63CaKb8hbxoL21izD58yr1NvhOhU=j+35+3og@mail.gmail.com/<br /> [5]: https://lore.kernel.org/bpf/CAAVpQUAHijOMext28Gi10dSLuMzGYh+jK61Ujn+fZ-wvcODR2A@mail.gmail.com/<br /> [6]: https://lore.kernel.org/bpf/dd043c69-4d03-46fe-8325-8f97101435cf@linux.dev/<br /> <br /> Summary of scenarios where af_unix/stream connect() may race a sockmap<br /> update:<br /> <br /> 1. connect() vs. bpf(BPF_MAP_UPDATE_ELEM), i.e. sock_map_update_elem_sys()<br /> <br /> Implemented NULL check is sufficient. Once assigned, socket peer won&amp;#39;t<br /> be released until socket fd is released. And that&amp;#39;s not an issue because<br /> sock_map_update_elem_sys() bumps fd refcnf.<br /> <br /> 2. connect() vs BPF program doing update<br /> <br /> Update restricted per verifier.c:may_update_sockmap() to<br /> <br /> BPF_PROG_TYPE_TRACING/BPF_TRACE_ITER<br /> BPF_PROG_TYPE_SOCK_OPS (bpf_sock_map_update() only)<br /> BPF_PROG_TYPE_SOCKET_FILTER<br /> BPF_PROG_TYPE_SCHED_CLS<br /> BPF_PROG_TYPE_SCHED_ACT<br /> BPF_PROG_TYPE_XDP<br /> BPF_PROG_TYPE_SK_REUSEPORT<br /> BPF_PROG_TYPE_FLOW_DISSECTOR<br /> BPF_PROG_TYPE_SK_LOOKUP<br /> <br /> Plus one more race to consider:<br /> <br /> CPU0 bpf CPU1 connect<br /> -------- ------------<br /> <br /> WRITE_ONCE(sk-&gt;sk_state, TCP_ESTABLISHED)<br /> sock_map_sk_state_allowed(sk)<br /> sock_hold(newsk)<br /> smp_mb__after_atomic()<br /> <br /> ---truncated---