On 2/4/26 20:34, Martin KaFai Lau wrote:

quoted

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?

$ 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