PT-2026-51928 · Linux · Linux

Published 2026-06-24 · Updated 2026-06-24 · CVE-2026-53034

Mitre

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

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

unix stream connect() sets sk state (WRITE ONCE(sk->sk state, TCP ESTABLISHED)) before it assigns a peer (unix peer(sk) = newsk). sk state == TCP ESTABLISHED makes sock map sk state allowed() believe that socket is properly set up, which would include having a defined peer. IOW, there's a window when unix stream bpf update proto() can be called on socket which still has unix peer(sk) == NULL.

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

            WRITE ONCE(sk->sk state, TCP ESTABLISHED)

sock map sk state allowed(sk) ... sk pair = unix peer(sk) sock hold(sk pair) sock hold(newsk) smp mb after atomic() unix peer(sk) = newsk

BUG: kernel NULL pointer dereference, address: 0000000000000080 RIP: 0010:unix stream bpf update proto+0xa0/0x1b0 Call Trace: sock map link+0x564/0x8b0 sock map update common+0x6e/0x340 sock map update elem sys+0x17d/0x240 sys bpf+0x26db/0x3250 x64 sys bpf+0x21/0x30 do syscall 64+0x6b/0x3a0 entry SYSCALL 64 after hwframe+0x76/0x7e

Initial idea was to move peer assignment before the sk state update1, but that involved an additional memory barrier, and changing the hot path was rejected. Then a NULL check during proto update in unix stream bpf update proto() was considered2, but the follow-up discussion3 focused on the root cause, i.e. sockmap update taking a wrong lock. Or, more specifically, missing unix state lock()[4]. In the end it was concluded that teaching sockmap about the af unix locking would be unnecessarily complex[5]. Complexity aside, since BPF PROG TYPE SCHED CLS and BPF PROG TYPE SCHED ACT are allowed to update sockmaps, sock map update elem() taking the unix lock, as it is currently implemented in unix state lock(): spin lock(&unix sk(s)->lock), would be problematic. unix state 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 idea2.

[4]: https://lore.kernel.org/netdev/CAAVpQUA+8GL j63CaKb8hbxoL21izD58yr1NvhOhU=[e-mail]/ [5]: https://lore.kernel.org/bpf/[e-mail]/ [6]: https://lore.kernel.org/bpf/[e-mail]/

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

1. connect() vs. bpf(BPF MAP UPDATE ELEM), i.e. sock map update elem 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 sock map update elem sys() bumps fd refcnf.

2. connect() vs BPF program doing update

Update restricted per verifier.c:may update sockmap() to

BPF PROG TYPE TRACING/BPF TRACE ITER BPF PROG TYPE SOCK OPS (bpf sock map update() only) BPF PROG TYPE SOCKET FILTER BPF PROG TYPE SCHED CLS BPF PROG TYPE SCHED ACT BPF PROG TYPE XDP BPF PROG TYPE SK REUSEPORT BPF PROG TYPE FLOW DISSECTOR BPF PROG TYPE SK LOOKUP

Plus one more race to consider:

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

              WRITE ONCE(sk->sk state, TCP ESTABLISHED)

sock map sk state allowed(sk) sock hold(newsk) smp mb after atomic()

---truncated---

Related Identifiers

CVE-2026-53034

Affected Products

Linux

References · 7

• https://nvd.nist.gov/vuln/detail/CVE-2026-53034 · Security Note
• https://git.kernel.org/stable/c/37bfcd164161b47d00b1c3bd20adc816a6977ce0 · Note
• https://git.kernel.org/stable/c/a94d3dd78ee8b63e6b8ad629081c952c93ee5a10 · Note
• https://git.kernel.org/stable/c/041eb6348d73ee5e15fc8161f1eac5a6e8289ca0 · Note
• https://git.kernel.org/stable/c/75b7d3b3f8bd4e59eb3af1b11a43c64c0c2db6f4 · Note
• https://git.kernel.org/stable/c/dca38b7734d2ea00af4818ff3ae836fab33d5d5a · Note
• https://git.kernel.org/stable/c/4913c94a3adcdbb64c552110c0c243cb1fdbb317 · Note