From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailtransmit05.runbox.com (mailtransmit05.runbox.com [185.226.149.38]) (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 3ACFC3368B2; Fri, 6 Mar 2026 14:07:12 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=185.226.149.38 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772806034; cv=none; b=kzJZuS4/bzyfGK4j0F6btD8TlHjIwT6+CtBLUARQ8Nh2UzHzAl8+4rJ8iR/ItfoeJVlUzdqCGKa5Jwc9dwp6IalPtSD6wRT0npdI4XYBVFUTwnvRzJ++EFUDQ/mVqaQSH2nbC6CEROyuApglYsopIIIGIM3wfEvzxLe47q8pKqY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772806034; c=relaxed/simple; bh=zOMrDzt6Kt+O7lNavb64k4pt1LqFU3bftY7nK/1uQZA=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=j44jUUMsZ3XI9fD1hkyLgxcsRT3ne7xevsuJSXVr5t86cVf6+bN74vcXcywQmu56m3E0QFH33B1NgYH2jK81tds4LMfj9rqj1JtfZX0e3BBHyisE2Jw33G1SsPP+mGYMsqEjnV1AmmTupMC4oXYfGSzHZSGsb/cUqC/2BFlGzYY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=rbox.co; spf=pass smtp.mailfrom=rbox.co; dkim=pass (2048-bit key) header.d=rbox.co header.i=@rbox.co header.b=tZ88noAj; arc=none smtp.client-ip=185.226.149.38 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=rbox.co Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=rbox.co Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=rbox.co header.i=@rbox.co header.b="tZ88noAj" Received: from mailtransmit02.runbox ([10.9.9.162] helo=aibo.runbox.com) by mailtransmit05.runbox.com with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.93) (envelope-from ) id 1vyVpA-00GQhD-Ue; Fri, 06 Mar 2026 15:06:40 +0100 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=rbox.co; s=selector1; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:From: References:Cc:To:Subject:MIME-Version:Date:Message-ID; bh=tC4hDySprxrT/Gr+j4+xPNKNNmZSdgwoLCHwVwT6ztI=; b=tZ88noAjFpW5Nv/sqE9VS4pza5 hPbP4uJ4fe57vF2JmAJ/yKvFEzygbyKWj3mC5t/ylL+43p/IFKIzQFzZyS3gjCR5V9WMm1IKZpBB3 liXKtSTtDgsyRZqZxlm79Ncm0HpPJOAXL1O81qTCMRBZKT1flLqgBD66rm8bkVA+XEthNDMYstXE8 ipngfsGAbLtFtLQ69Dhze++67yIKq+eqE5UE0gUa+MZKStoDUec4Y7XjHz5kJ/FLuw84ZSbd6tGgr 3U6P4zbehVpOOi+kfCEndJeH8JYHTsoksN9R/BTXvYp3mzsgfBRbcdsT1jsSEz+OGyxDq91UQbDMl 3JvQNP/A==; Received: from [10.9.9.74] (helo=submission03.runbox) by mailtransmit02.runbox with esmtp (Exim 4.86_2) (envelope-from ) id 1vyVpA-0001kw-Ba; Fri, 06 Mar 2026 15:06:40 +0100 Received: by submission03.runbox with esmtpsa [Authenticated ID (604044)] (TLS1.2:ECDHE_SECP256R1__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) (Exim 4.93) id 1vyVor-0008GC-Mo; Fri, 06 Mar 2026 15:06:21 +0100 Message-ID: <6b02c177-69a2-4e08-a936-65bfa8e85b7e@rbox.co> Date: Fri, 6 Mar 2026 15:06:18 +0100 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH bpf v3 3/5] bpf, sockmap: Fix af_unix iter deadlock To: Jiayuan Chen , John Fastabend , Jakub Sitnicki , Eric Dumazet , Kuniyuki Iwashima , Paolo Abeni , Willem de Bruijn , "David S. Miller" , Jakub Kicinski , Simon Horman , Yonghong Song , Andrii Nakryiko , Alexei Starovoitov , Daniel Borkmann , Martin KaFai Lau , Eduard Zingerman , Song Liu , Yonghong Song , KP Singh , Stanislav Fomichev , Hao Luo , Jiri Olsa , Shuah Khan , Cong Wang Cc: netdev@vger.kernel.org, bpf@vger.kernel.org, linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org References: <20260306-unix-proto-update-null-ptr-deref-v3-0-2f0c7410c523@rbox.co> <20260306-unix-proto-update-null-ptr-deref-v3-3-2f0c7410c523@rbox.co> Content-Language: pl-PL, en-GB From: Michal Luczaj In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 3/6/26 07:04, Jiayuan Chen wrote: > On 3/6/26 7:30 AM, Michal Luczaj wrote: >> @@ -3729,15 +3729,14 @@ static int bpf_iter_unix_seq_show(struct seq_file *seq, void *v) >> struct bpf_prog *prog; >> struct sock *sk = v; >> uid_t uid; >> - bool slow; >> int ret; >> >> if (v == SEQ_START_TOKEN) >> return 0; >> >> - slow = lock_sock_fast(sk); >> + lock_sock(sk); >> >> - if (unlikely(sk_unhashed(sk))) { >> + if (unlikely(sock_flag(sk, SOCK_DEAD))) { >> ret = SEQ_SKIP; >> goto unlock; >> } > > > Switching to lock_sock() fixes the deadlock, but it does not provide mutual > exclusion with unix_release_sock(), which uses unix_state_lock() exclusively > and does not touch lock_sock() at all. So a dying socket can still reach the > BPF prog concurrently with unix_release_sock() running on another CPU. That's right. Note that although the socket is dying, iter holds a reference to it, so the socket is far from being freed (as in: memory released). > Both SOCK_DEAD and the clearing of unix_peer(sk) happen under > unix_state_lock() in unix_release_sock(). Without taking unix_state_lock() > before the SOCK_DEAD check, there is a window: > > iter unix_release_sock() > --- lock_sock(sk) > SOCK_DEAD == 0 (check passes) > unix_state_lock(sk) > unix_peer(sk) = NULL > sock_set_flag(sk, SOCK_DEAD) > unix_state_unlock(sk) > BPF prog runs > → accesses unix_peer(sk) == NULL → crash > > This was not raised in the v2 discussion. It was raised in v1[1]. Conclusion was that bpf prog bytecode directly accessing unix_peer(sk) is not an issue; bpf machinery will handle any faults. That said, should a "bad" value of unix_peer(sk) end up as a parameter of a bpf helper, yes, that is a well known[2] problem (that have a solution unrelated to this series). [1]: https://lore.kernel.org/bpf/6de6f1bf-c8ee-4dfb-9b8c-f89185946630@linux.dev/ [2]: https://lore.kernel.org/bpf/CAADnVQK_93g_KkNFYXSr8ZvA1fYh4hoFRJCJFPS-zs4ox0HhAA@mail.gmail.com/