CVE-2026-53034

In the Linux kernel, the following vulnerability has been resolved:

bpf, sockmap: Fix af_unix null-ptr-deref in proto update

unixstreamconnect() sets skstate (WRITE_ONCE(sk->sk_state, TCP_ESTABLISHED)) before it assigns a peer (unix_peer(sk) = newsk). skstate == TCPESTABLISHED makes sockmapskstateallowed() believe that socket is properly set up, which would include having a defined peer. IOW, there's a window when unixstreambpfupdateproto() can be called on socket which still has unixpeer(sk) == NULL.

     CPU0 bpf                            CPU1 connect
     --------                            ------------

                            WRITE_ONCE(sk->sk_state, TCP_ESTABLISHED)

sockmapskstateallowed(sk) ... skpair = unixpeer(sk) sockhold(skpair) sockhold(newsk) smpmb__afteratomic() unixpeer(sk) = newsk

BUG: kernel NULL pointer dereference, address: 0000000000000080 RIP: 0010:unixstreambpfupdateproto+0xa0/0x1b0 Call Trace: sockmaplink+0x564/0x8b0 sockmapupdatecommon+0x6e/0x340 sockmapupdateelem_sys+0x17d/0x240 __sys_bpf+0x26db/0x3250 __x64sysbpf+0x21/0x30 dosyscall64+0x6b/0x3a0 entrySYSCALL64afterhwframe+0x76/0x7e

Initial idea was to move peer assignment before the skstate update[1], but that involved an additional memory barrier, and changing the hot path was rejected. Then a NULL check during proto update in unixstreambpfupdateproto() was considered[2], but the follow-up discussion[3] focused on the root cause, i.e. sockmap update taking a wrong lock. Or, more specifically, missing unixstatelock()[4]. In the end it was concluded that teaching sockmap about the afunix locking would be unnecessarily complex[5]. Complexity aside, since BPFPROGTYPESCHEDCLS and BPFPROGTYPESCHEDACT are allowed to update sockmaps, sockmapupdateelem() taking the unix lock, as it is currently implemented in unixstatelock(): spinlock(&unixsk(s)->lock), would be problematic. unixstate_lock() taken in a process context, followed by a softirq-context TC BPF program attempting to take the same spinlock -- deadlock[6]. This way we circled back to the peer check idea[2].

Summary of scenarios where af_unix/stream connect() may race a sockmap update:

1. connect() vs. bpf(BPFMAPUPDATEELEM), i.e. sockmapupdateelem_sys()

   Implemented NULL check is sufficient. Once assigned, socket peer won't be released until socket fd is released. And that's not an issue because sockmapupdateelemsys() bumps fd refcnf.

2. connect() vs BPF program doing update

   Update restricted per verifier.c:mayupdatesockmap() to

   BPFPROGTYPETRACING/BPFTRACEITER BPFPROGTYPESOCKOPS (bpfsockmapupdate() only) BPFPROGTYPESOCKETFILTER BPFPROGTYPESCHEDCLS BPFPROGTYPESCHEDACT BPFPROGTYPEXDP BPFPROGTYPESKREUSEPORT BPFPROGTYPEFLOWDISSECTOR BPFPROGTYPESK_LOOKUP

   Plus one more race to consider:

        CPU0 bpf                            CPU1 connect
        --------                            ------------
   
                               WRITE_ONCE(sk->sk_state, TCP_ESTABLISHED)
   

   sockmapskstateallowed(sk) sockhold(newsk) smpmb_afteratomic()

---truncated---