From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-170.mta0.migadu.com (out-170.mta0.migadu.com [91.218.175.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 4367D2AD32 for ; Thu, 5 Feb 2026 00:31:57 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=91.218.175.170 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770251517; cv=none; b=fALmljiwuoyjTYsuZ95A318dIb0aYxlEvbHR5OUgOLTci5Gzyzj7Nz5lO6T+jJcFePeCvBxnYh5e0UGIttdFB/u5RCjP6aMUag/QoVh1ljRneu3OumSbNgfjXG6gP4rdTgIgylOcgfej3Kh5Nsrbi3j6pqNJexS7J7Ws2AXQLAE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770251517; c=relaxed/simple; bh=n9fHcu8iZOUYTF8e/Bf3Uxj0xVdGkFnoJ1+rpmRkZYQ=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=cpBBNE74i8pNGkgzcxlBQBnPaxcJRDrcWxJWe4V5kFrq6z/ypH7A87gZUbWV2jBsDf48f7LQQ9C1yaxKEhCMl37PFmKa92Uh9FzhNLgWctbm0VTwLjcyJoOgjsxt5QStAqfQvSSKQohLJcZRZqsF3I1Rk92/A60QWFu+UGRK7Pc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b=JI7mvZkY; arc=none smtp.client-ip=91.218.175.170 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="JI7mvZkY" Message-ID: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1770251505; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=lM/MzMow83GadW34Ofqq1msI3+/k3/l0eZ4j44zqwbk=; b=JI7mvZkYjHQAx3QYwclZ4I/BOWiSc7IXVIScGIBAv4EgPh1dwaXxNw5OWCYQbg7GamihBN 84V5V6BvlXyff9SEr8tcFkzsvvGWB763XjHxp+kGCsK2mL8GSWT8/eiBVLFR3ga/JrpapC /X7PcxIiE5kDK2kcNHpacqeKbQfn6Jg= Date: Wed, 4 Feb 2026 16:31:32 -0800 Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Subject: Re: [PATCH bpf] bpf, sockmap: Fix af_unix null-ptr-deref in proto update To: Michal Luczaj , Kuniyuki Iwashima Cc: bpf@vger.kernel.org, daniel@iogearbox.net, davem@davemloft.net, edumazet@google.com, horms@kernel.org, jakub@cloudflare.com, john.fastabend@gmail.com, kuba@kernel.org, linux-kernel@vger.kernel.org, netdev@vger.kernel.org, pabeni@redhat.com References: <8d055903-fe44-4bbf-a1a5-e0176343bf0b@rbox.co> <20260203200242.404131-1-kuniyu@google.com> <80865b12-7786-4787-81c8-08b754716a5d@linux.dev> <408569e7-2b82-4eff-b767-79ce6ef6cae0@rbox.co> <0f8ec4c7-5de4-4e0b-a50e-cf4f8d59709b@linux.dev> <37a594f4-a951-4283-80eb-67b6acecf61f@rbox.co> Content-Language: en-US X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Martin KaFai Lau In-Reply-To: <37a594f4-a951-4283-80eb-67b6acecf61f@rbox.co> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Migadu-Flow: FLOW_OUT 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.