On 2/4/26 3:25 PM, Michal Luczaj wrote:

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

quoted

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?

fexit is an obvious one if the bpf prog wants to shoot itself on the 
foot by using things at the fexit of a free/release function. There are 
other things can break also if a tracing-capable user wants to exploit 
at fexit. I don't have good idea how to solve it.

Going back to the bpf_skc_to_* helper. The bigger hammer may be, we 
should properly depreciate the bpf_skc_to_* usage from tracing instead 
of fixing it and ask the user to stay with the bpf_core_cast.