linux-kernel - Re: [PATCH bpf] bpf, sockmap: Fix af_unix null-ptr-deref in proto update

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAAVpQUAi2WFMz3fZutKgJGjVnMh8LMiw1GM+M9L-Gt-NuHghBg@mail.gmail.com>
Date: Wed, 4 Feb 2026 16:27:04 -0800
From: Kuniyuki Iwashima <kuniyu@...gle.com>
To: Michal Luczaj <mhal@...x.co>
Cc: Martin KaFai Lau <martin.lau@...ux.dev>, bpf@...r.kernel.org, daniel@...earbox.net, 
	davem@...emloft.net, edumazet@...gle.com, horms@...nel.org, 
	jakub@...udflare.com, john.fastabend@...il.com, kuba@...nel.org, 
	linux-kernel@...r.kernel.org, netdev@...r.kernel.org, pabeni@...hat.com
Subject: Re: [PATCH bpf] bpf, sockmap: Fix af_unix null-ptr-deref in proto update

On Wed, Feb 4, 2026 at 3:25 PM Michal Luczaj <mhal@...x.co> wrote:
>
> On 2/4/26 20:34, Martin KaFai Lau wrote:
> >> But then there's SOCK_DGRAM where you can drop unix_peer(sk) without
> >> releasing sk; see AF_UNSPEC in unix_dgram_connect(). I think Martin is
> >> right, we can crash at many fentries.
> >>
> >> BUG: KASAN: slab-use-after-free in bpf_skc_to_unix_sock+0xa4/0xb0
> >> Read of size 2 at addr ffff888147d38890 by task test_progs/2495
> >> Call Trace:
> >>   dump_stack_lvl+0x5d/0x80
> >>   print_report+0x170/0x4f3
> >>   kasan_report+0xe1/0x180
> >>   bpf_skc_to_unix_sock+0xa4/0xb0
> >>   bpf_prog_564a1c39c35d86a2_unix_shutdown_entry+0x8a/0x8e
> >>   bpf_trampoline_6442564662+0x47/0xab
> >>   unix_shutdown+0x9/0x880
> >>   __sys_shutdown+0xe1/0x160
> >>   __x64_sys_shutdown+0x52/0x90
> >>   do_syscall_64+0x6b/0x3a0
> >>   entry_SYSCALL_64_after_hwframe+0x76/0x7e
> >
> > This probably is the first case where reading a sk pointer requires a
> > lock. I think it will need to be marked as PTR_UNTRUSTED in the verifier
> > for the unix->peer access, so that it cannot be passed to a helper.
> > There is a BTF_TYPE_SAFE_TRUSTED list. afaik, there is no untrusted one now.
>
> What about 'fexit/sk_common_release' that does 'bpf_skc_to_unix_sock(sk)'.
> Is this something the verifies is supposed to handle?

sk_common_release() is not called from AF_UNIX and
even other helpers accessing sk->sk_xxx should trigger the
same splat.  Moreover, any read would trigger the splat at
other functions like sk_prot_free().

We could sprinkle notrace over the kernel or have a blocked
list for each helper in the verifier, but then we need to inspect
all bpf helpers.

In the first place, it makes no sense that someone who knows
where a pointer is freed tries to read it after being freed and
complains about UAF :/



>
> $ python -c 'from socket import *; socket(AF_INET, SOCK_DGRAM)'
>
> BUG: KASAN: slab-use-after-free in bpf_skc_to_unix_sock+0x95/0xb0
> Read of size 1 at addr ffff888128312112 by task python/4076
> Call Trace:
>  dump_stack_lvl+0x5d/0x80
>  print_report+0x170/0x4f3
>  kasan_report+0xe1/0x180
>  bpf_skc_to_unix_sock+0x95/0xb0
>  bpf_prog_70a8d38bd5dbf399_release_exit+0x87/0x8b
>  bpf_trampoline_6442556594+0x64/0xd3
>  inet_release+0x104/0x230
>  __sock_release+0xb0/0x270
>  sock_close+0x18/0x20
>  __fput+0x36e/0xac0
>  fput_close_sync+0xe5/0x1a0
>  __x64_sys_close+0x7d/0xd0
>  do_syscall_64+0x6b/0x3a0
>  entry_SYSCALL_64_after_hwframe+0x76/0x7e
>