{"id":"CVE-2026-53034","summary":"bpf, sockmap: Fix af_unix null-ptr-deref in proto update","details":"In the Linux kernel, the following vulnerability has been resolved:\n\nbpf, sockmap: Fix af_unix null-ptr-deref in proto update\n\nunix_stream_connect() sets sk_state (`WRITE_ONCE(sk-\u003esk_state,\nTCP_ESTABLISHED)`) _before_ it assigns a peer (`unix_peer(sk) = newsk`).\nsk_state == TCP_ESTABLISHED makes sock_map_sk_state_allowed() believe that\nsocket is properly set up, which would include having a defined peer. IOW,\nthere's a window when unix_stream_bpf_update_proto() can be called on\nsocket which still has unix_peer(sk) == NULL.\n\n         CPU0 bpf                            CPU1 connect\n         --------                            ------------\n\n                                WRITE_ONCE(sk-\u003esk_state, TCP_ESTABLISHED)\nsock_map_sk_state_allowed(sk)\n...\nsk_pair = unix_peer(sk)\nsock_hold(sk_pair)\n                                sock_hold(newsk)\n                                smp_mb__after_atomic()\n                                unix_peer(sk) = newsk\n\nBUG: kernel NULL pointer dereference, address: 0000000000000080\nRIP: 0010:unix_stream_bpf_update_proto+0xa0/0x1b0\nCall Trace:\n  sock_map_link+0x564/0x8b0\n  sock_map_update_common+0x6e/0x340\n  sock_map_update_elem_sys+0x17d/0x240\n  __sys_bpf+0x26db/0x3250\n  __x64_sys_bpf+0x21/0x30\n  do_syscall_64+0x6b/0x3a0\n  entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\nInitial idea was to move peer assignment _before_ the sk_state update[1],\nbut that involved an additional memory barrier, and changing the hot path\nwas rejected.\nThen a NULL check during proto update in unix_stream_bpf_update_proto() was\nconsidered[2], but the follow-up discussion[3] focused on the root cause,\ni.e. sockmap update taking a wrong lock. Or, more specifically, missing\nunix_state_lock()[4].\nIn the end it was concluded that teaching sockmap about the af_unix locking\nwould be unnecessarily complex[5].\nComplexity aside, since BPF_PROG_TYPE_SCHED_CLS and BPF_PROG_TYPE_SCHED_ACT\nare allowed to update sockmaps, sock_map_update_elem() taking the unix\nlock, as it is currently implemented in unix_state_lock():\nspin_lock(&unix_sk(s)-\u003elock), would be problematic. unix_state_lock() taken\nin a process context, followed by a softirq-context TC BPF program\nattempting to take the same spinlock -- deadlock[6].\nThis way we circled back to the peer check idea[2].\n\n[1]: https://lore.kernel.org/netdev/ba5c50aa-1df4-40c2-ab33-a72022c5a32e@rbox.co/\n[2]: https://lore.kernel.org/netdev/20240610174906.32921-1-kuniyu@amazon.com/\n[3]: https://lore.kernel.org/netdev/7603c0e6-cd5b-452b-b710-73b64bd9de26@linux.dev/\n[4]: https://lore.kernel.org/netdev/CAAVpQUA+8GL_j63CaKb8hbxoL21izD58yr1NvhOhU=j+35+3og@mail.gmail.com/\n[5]: https://lore.kernel.org/bpf/CAAVpQUAHijOMext28Gi10dSLuMzGYh+jK61Ujn+fZ-wvcODR2A@mail.gmail.com/\n[6]: https://lore.kernel.org/bpf/dd043c69-4d03-46fe-8325-8f97101435cf@linux.dev/\n\nSummary of scenarios where af_unix/stream connect() may race a sockmap\nupdate:\n\n1. connect() vs. bpf(BPF_MAP_UPDATE_ELEM), i.e. sock_map_update_elem_sys()\n\n   Implemented NULL check is sufficient. Once assigned, socket peer won't\n   be released until socket fd is released. And that's not an issue because\n   sock_map_update_elem_sys() bumps fd refcnf.\n\n2. connect() vs BPF program doing update\n\n   Update restricted per verifier.c:may_update_sockmap() to\n\n      BPF_PROG_TYPE_TRACING/BPF_TRACE_ITER\n      BPF_PROG_TYPE_SOCK_OPS (bpf_sock_map_update() only)\n      BPF_PROG_TYPE_SOCKET_FILTER\n      BPF_PROG_TYPE_SCHED_CLS\n      BPF_PROG_TYPE_SCHED_ACT\n      BPF_PROG_TYPE_XDP\n      BPF_PROG_TYPE_SK_REUSEPORT\n      BPF_PROG_TYPE_FLOW_DISSECTOR\n      BPF_PROG_TYPE_SK_LOOKUP\n\n   Plus one more race to consider:\n\n            CPU0 bpf                            CPU1 connect\n            --------                            ------------\n\n                                   WRITE_ONCE(sk-\u003esk_state, TCP_ESTABLISHED)\n   sock_map_sk_state_allowed(sk)\n                                   sock_hold(newsk)\n                                   smp_mb__after_atomic()\n                \n---truncated---","modified":"2026-07-12T03:54:52.801755044Z","published":"2026-06-24T16:29:41.676Z","database_specific":{"cna_assigner":"Linux","osv_generated_from":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/53xxx/CVE-2026-53034.json"},"references":[{"type":"WEB","url":"https://git.kernel.org/stable/c/041eb6348d73ee5e15fc8161f1eac5a6e8289ca0"},{"type":"WEB","url":"https://git.kernel.org/stable/c/37bfcd164161b47d00b1c3bd20adc816a6977ce0"},{"type":"WEB","url":"https://git.kernel.org/stable/c/4913c94a3adcdbb64c552110c0c243cb1fdbb317"},{"type":"WEB","url":"https://git.kernel.org/stable/c/75b7d3b3f8bd4e59eb3af1b11a43c64c0c2db6f4"},{"type":"WEB","url":"https://git.kernel.org/stable/c/a94d3dd78ee8b63e6b8ad629081c952c93ee5a10"},{"type":"WEB","url":"https://git.kernel.org/stable/c/dca38b7734d2ea00af4818ff3ae836fab33d5d5a"},{"type":"ADVISORY","url":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/53xxx/CVE-2026-53034.json"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-53034"},{"type":"PACKAGE","url":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git"}],"affected":[{"ranges":[{"type":"GIT","repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","events":[{"introduced":"c63829182c37c2d6d0608976d15fa61ebebe9e6b"},{"fixed":"75b7d3b3f8bd4e59eb3af1b11a43c64c0c2db6f4"},{"fixed":"a94d3dd78ee8b63e6b8ad629081c952c93ee5a10"},{"fixed":"4913c94a3adcdbb64c552110c0c243cb1fdbb317"},{"fixed":"041eb6348d73ee5e15fc8161f1eac5a6e8289ca0"},{"fixed":"37bfcd164161b47d00b1c3bd20adc816a6977ce0"},{"fixed":"dca38b7734d2ea00af4818ff3ae836fab33d5d5a"}]}],"database_specific":{"source":"https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-53034.json"}},{"package":{"name":"Kernel","ecosystem":"Linux"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"5.15.0"},{"fixed":"6.1.175"}]},{"type":"ECOSYSTEM","events":[{"introduced":"6.2.0"},{"fixed":"6.6.141"}]},{"type":"ECOSYSTEM","events":[{"introduced":"6.7.0"},{"fixed":"6.12.91"}]},{"type":"ECOSYSTEM","events":[{"introduced":"6.13.0"},{"fixed":"6.18.33"}]},{"type":"ECOSYSTEM","events":[{"introduced":"6.19.0"},{"fixed":"7.0.10"}]}],"database_specific":{"source":"https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-53034.json"}}],"schema_version":"1.7.5"}