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: <c4b5aba5-ec48-4329-9549-b5c96de40c69@linux.dev>
Date: Wed, 4 Feb 2026 16:31:32 -0800
From: Martin KaFai Lau <martin.lau@...ux.dev>
To: Michal Luczaj <mhal@...x.co>, Kuniyuki Iwashima <kuniyu@...gle.com>
Cc: 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 2/4/26 3:25 PM, Michal Luczaj 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?

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.