On 2/3/26 04:53, Martin KaFai Lau wrote:

On 2/2/26 7:10 AM, Michal Luczaj wrote:

quoted

In related news, looks like bpf_iter_unix_seq_show() is missing
unix_state_lock(): lock_sock_fast() won't stop unix_release_sock(). E.g.
bpf iterator can grab unix_sock::peer as it is being released.

If the concern is the bpf iterator prog may use a released unix_peer(sk) 
pointer, it should be fine. The unix_peer(sk) pointer is not a trusted 
pointer to the bpf prog, so nothing bad will happen other than 
potentially reading incorrect values.

But if the prog passes a released peer pointer to a bpf helper:

BUG: KASAN: slab-use-after-free in bpf_skc_to_unix_sock+0x95/0xb0
Read of size 1 at addr ffff888110654c92 by task test_progs/1936
Call Trace:
 dump_stack_lvl+0x5d/0x80
 print_report+0x170/0x4f3
 kasan_report+0xe1/0x180
 bpf_skc_to_unix_sock+0x95/0xb0
 bpf_prog_382743e45576abd5_dump_unix+0x4a0/0x576
 bpf_iter_run_prog+0x5b9/0xb00
 bpf_iter_unix_seq_show+0x1f7/0x2e0
 bpf_seq_read+0x42c/0x10d0
 vfs_read+0x171/0xb20
 ksys_read+0xff/0x200
 do_syscall_64+0x6b/0x3a0
 entry_SYSCALL_64_after_hwframe+0x76/0x7e

Allocated by task 1941:
 kasan_save_stack+0x30/0x50
 kasan_save_track+0x14/0x30
 __kasan_slab_alloc+0x63/0x80
 kmem_cache_alloc_noprof+0x1f7/0x6f0
 sk_prot_alloc+0x59/0x210
 sk_alloc+0x34/0x470
 unix_create1+0x86/0x8a0
 unix_create+0xd4/0x2d0
 __sock_create+0x243/0x5a0
 __sys_socket+0x119/0x1d0
 __x64_sys_socket+0x72/0xd0
 do_syscall_64+0x6b/0x3a0
 entry_SYSCALL_64_after_hwframe+0x76/0x7e

Freed by task 1941:
 kasan_save_stack+0x30/0x50
 kasan_save_track+0x14/0x30
 kasan_save_free_info+0x3b/0x70
 __kasan_slab_free+0x47/0x70
 kmem_cache_free+0x12c/0x5d0
 __sk_destruct+0x432/0x6e0
 unix_release_sock+0x9b3/0xf60
 unix_release_sock+0x99f/0xf60
 unix_release+0x8a/0xf0
 __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