From nobody Thu Apr 23 10:30:52 2026 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 4B18C3E8681; Tue, 14 Apr 2026 14:14:05 +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=1776176047; cv=none; b=hbXfi6qiak/A/xttboKr9G8R0PUR5i5TywIRvqt5/ACvwysnDuoDwH9U+d8nHvLP+Xdw0tdbcAQuHCV/58yx2TTGADVcNL/HlPDuec22DDj4JIiuN9HiZVdEXEb000um6TZzsjhIP3KD80sdd6rst0b/Qb8clsa3Kz7kISUnPtI= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776176047; c=relaxed/simple; bh=nT2Tj4WN5nVASsWR0Rf23HRLAUy4aZ6TkvIacAn1giY=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=QCCbG8iaHCRGC8Lxc0jMBShEoi6PozvyiizXJm5GI4l8szGI+HwuI8SGe/xVRaqf2WUf0wONzO5kKmcuNdby5UHiOfr+Yv0OIZhUPzBy1IyK0c7kKcJ8R49LzCjAtdApCXthVnz0q7M5JDst8c091d7blgvYJrUcHXHFWyHURzE= 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=TmWXK9Mc; 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="TmWXK9Mc" 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 1wCeWO-00Fdqc-Fw; Tue, 14 Apr 2026 16:13:44 +0200 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=rbox.co; s=selector1; h=Cc:To:In-Reply-To:References:Message-Id: Content-Transfer-Encoding:Content-Type:MIME-Version:Subject:Date:From; bh=BieWsBuZObwE52NomKb0T7XPKPlqeO+dDW3yQZ5Qiqo=; b=TmWXK9McvraL/uU6NzggGfFs+p 9DSFlGdxaC8b5SZUsjm6lDdacAi2SO3Tq2fIo0/POPCMlvr+4EtaJIiXl9TwmXaN/bUdUjK2uyxbQ SlXHukDi710aZ0rHaZDWNH+b9RzU6h15dvrtxdHPEaFIRB1H35GhaHecqkdDVXG5VAkMyp4LeNzD1 8NfsfIhwVvjSSPEP4AieQcL6zHcA+T6nKb6TE0vpWNcvI9AKalWfNmUt3EpfBeUwABxoVbtuQRZSC LHfJSZHOFs/NE7y8fj3sDPF2g+oL6ZuTfh+C7qWt94UNQBgPttDNpzxQ78tuVB67TQBl5EGJD0QBY 4GaOezLQ==; Received: from [10.9.9.72] (helo=submission01.runbox) by mailtransmit02.runbox with esmtp (Exim 4.86_2) (envelope-from ) id 1wCeWO-0000Vs-0e; Tue, 14 Apr 2026 16:13:44 +0200 Received: by submission01.runbox with esmtpsa [Authenticated ID (604044)] (TLS1.2:ECDHE_SECP256R1__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) (Exim 4.93) id 1wCeWA-00DhbX-2Q; Tue, 14 Apr 2026 16:13:30 +0200 From: Michal Luczaj Date: Tue, 14 Apr 2026 16:13:15 +0200 Subject: [PATCH bpf v4 1/5] bpf, sockmap: Annotate af_unix sock::sk_state data-races Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <20260414-unix-proto-update-null-ptr-deref-v4-1-2af6fe97918e@rbox.co> References: <20260414-unix-proto-update-null-ptr-deref-v4-0-2af6fe97918e@rbox.co> In-Reply-To: <20260414-unix-proto-update-null-ptr-deref-v4-0-2af6fe97918e@rbox.co> To: 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, Michal Luczaj , Jiayuan Chen X-Mailer: b4 0.15.2 sock_map_sk_state_allowed() and sock_map_redirect_allowed() read af_unix socket sk_state locklessly. Use READ_ONCE(). Note that for sock_map_redirect_allowed() change affects not only af_unix, but all non-TCP sockets (UDP, af_vsock). Suggested-by: Kuniyuki Iwashima Suggested-by: Martin KaFai Lau Reviewed-by: Jiayuan Chen Reviewed-by: Kuniyuki Iwashima Signed-off-by: Michal Luczaj --- net/core/sock_map.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/net/core/sock_map.c b/net/core/sock_map.c index b0e96337a269..02a68be3002a 100644 --- a/net/core/sock_map.c +++ b/net/core/sock_map.c @@ -530,7 +530,7 @@ static bool sock_map_redirect_allowed(const struct sock= *sk) if (sk_is_tcp(sk)) return sk->sk_state !=3D TCP_LISTEN; else - return sk->sk_state =3D=3D TCP_ESTABLISHED; + return READ_ONCE(sk->sk_state) =3D=3D TCP_ESTABLISHED; } =20 static bool sock_map_sk_is_suitable(const struct sock *sk) @@ -543,7 +543,7 @@ static bool sock_map_sk_state_allowed(const struct sock= *sk) if (sk_is_tcp(sk)) return (1 << sk->sk_state) & (TCPF_ESTABLISHED | TCPF_LISTEN); if (sk_is_stream_unix(sk)) - return (1 << sk->sk_state) & TCPF_ESTABLISHED; + return (1 << READ_ONCE(sk->sk_state)) & TCPF_ESTABLISHED; if (sk_is_vsock(sk) && (sk->sk_type =3D=3D SOCK_STREAM || sk->sk_type =3D=3D SOCK_SEQPACKET)) return (1 << sk->sk_state) & TCPF_ESTABLISHED; --=20 2.53.0 From nobody Thu Apr 23 10:30:52 2026 Received: from mailtransmit04.runbox.com (mailtransmit04.runbox.com [185.226.149.37]) (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 19E66256C61; Tue, 14 Apr 2026 15:11:42 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=185.226.149.37 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776179505; cv=none; b=RauuJlunW/cJdGDrcS5HQjVm7of0ZHjjTi8qc4W/CYk/rNhpm1t4MlVoG7NawnQUUkG6pSHuwYMstErRZvFxqIPlWyLaMC95nTD73D6zn+4h1XDANjTuyQvMorRDTvfsq8xbYn9RSFNalK75+ZCSrR3PzWQx3Xhk7yF3xwN/3oA= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776179505; c=relaxed/simple; bh=tp2zXVzdAJ5XOEiTCsRkb3jbGLsEwShzGi5kuermpAc=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=gIXO1vhtEZziqhJZBb1wurncAixIbtsSEE4mXLpAlYlR/FhCZ+aT39gYXUVKBgVLfeTD5QD3oYDDeMbWLkrylHNKLo3HHBcP96/gDuzBfCS/ye+vmFEpi7MomNz+qs8f7fvSyzZhW1NHi8eL7Jd0kaYR/T0xSZekndX2iQXFFdg= 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=evp0a+zh; arc=none smtp.client-ip=185.226.149.37 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="evp0a+zh" Received: from mailtransmit02.runbox ([10.9.9.162] helo=aibo.runbox.com) by mailtransmit04.runbox.com with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.93) (envelope-from ) id 1wCeWL-00FB5b-Nm; Tue, 14 Apr 2026 16:13:41 +0200 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=rbox.co; s=selector1; h=Cc:To:In-Reply-To:References:Message-Id: Content-Transfer-Encoding:Content-Type:MIME-Version:Subject:Date:From; bh=mJIuV1hFcG0AqFmXjuVmJdTq5oqD37Hr+RkhyPIT/fw=; b=evp0a+zhKZ19/tsYUtmJ1rGgiq i0W3zfkwG/OaN3LhGGjEC4UXYU4KDsxr9TrXWuP6GuLHX36a4GwBGeb4xusowreSSKEvqZWt9KofG D5I+ZPzmEzU3n6XWZo1ZLaW4TcC8IwLcCzCkxOYsbUB9TwM9Jg8Nuw5Jz1QiavTCuYELdwwG98sCs QJ1mQCVpJEmZWT+Dg4X7VnOobXBI6YYJPcDIQ0bmbgoiwBAnPAuw5kc83nXfQW4YYLWRfj87AYNNg A6JboP87w8dYhJHKqf0DsyQS5BD0Abs/P6MllJ7qFjzVwLrJhPJWHdjLe2rdy2cjx4RxKxIHmIe4T Sd4d7rrg==; Received: from [10.9.9.72] (helo=submission01.runbox) by mailtransmit02.runbox with esmtp (Exim 4.86_2) (envelope-from ) id 1wCeWL-0000Ul-FU; Tue, 14 Apr 2026 16:13:41 +0200 Received: by submission01.runbox with esmtpsa [Authenticated ID (604044)] (TLS1.2:ECDHE_SECP256R1__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) (Exim 4.93) id 1wCeWB-00DhbX-F5; Tue, 14 Apr 2026 16:13:31 +0200 From: Michal Luczaj Date: Tue, 14 Apr 2026 16:13:16 +0200 Subject: [PATCH bpf v4 2/5] bpf, sockmap: Fix af_unix iter deadlock Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <20260414-unix-proto-update-null-ptr-deref-v4-2-2af6fe97918e@rbox.co> References: <20260414-unix-proto-update-null-ptr-deref-v4-0-2af6fe97918e@rbox.co> In-Reply-To: <20260414-unix-proto-update-null-ptr-deref-v4-0-2af6fe97918e@rbox.co> To: 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, Michal Luczaj , Jiayuan Chen X-Mailer: b4 0.15.2 bpf_iter_unix_seq_show() may deadlock when lock_sock_fast() takes the fast path and the iter prog attempts to update a sockmap. Which ends up spinning at sock_map_update_elem()'s bh_lock_sock(): WARNING: possible recursive locking detected test_progs/1393 is trying to acquire lock: ffff88811ec25f58 (slock-AF_UNIX){+...}-{3:3}, at: sock_map_update_elem+0xdb= /0x1f0 but task is already holding lock: ffff88811ec25f58 (slock-AF_UNIX){+...}-{3:3}, at: __lock_sock_fast+0x37/0xe0 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(slock-AF_UNIX); lock(slock-AF_UNIX); *** DEADLOCK *** May be due to missing lock nesting notation 4 locks held by test_progs/1393: #0: ffff88814b59c790 (&p->lock){+.+.}-{4:4}, at: bpf_seq_read+0x59/0x10d0 #1: ffff88811ec25fd8 (sk_lock-AF_UNIX){+.+.}-{0:0}, at: bpf_seq_read+0x42c= /0x10d0 #2: ffff88811ec25f58 (slock-AF_UNIX){+...}-{3:3}, at: __lock_sock_fast+0x3= 7/0xe0 #3: ffffffff85a6a7c0 (rcu_read_lock){....}-{1:3}, at: bpf_iter_run_prog+0x= 51d/0xb00 Call Trace: dump_stack_lvl+0x5d/0x80 print_deadlock_bug.cold+0xc0/0xce __lock_acquire+0x130f/0x2590 lock_acquire+0x14e/0x2b0 _raw_spin_lock+0x30/0x40 sock_map_update_elem+0xdb/0x1f0 bpf_prog_2d0075e5d9b721cd_dump_unix+0x55/0x4f4 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 Suggested-by: Kuniyuki Iwashima Suggested-by: Martin KaFai Lau Fixes: 2c860a43dd77 ("bpf: af_unix: Implement BPF iterator for UNIX domain = socket.") Reviewed-by: Jiayuan Chen Reviewed-by: Kuniyuki Iwashima Signed-off-by: Michal Luczaj --- net/unix/af_unix.c | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/net/unix/af_unix.c b/net/unix/af_unix.c index b23c33df8b46..590a30d3b2f7 100644 --- a/net/unix/af_unix.c +++ b/net/unix/af_unix.c @@ -3731,15 +3731,14 @@ static int bpf_iter_unix_seq_show(struct seq_file *= seq, void *v) struct bpf_prog *prog; struct sock *sk =3D v; uid_t uid; - bool slow; int ret; =20 if (v =3D=3D SEQ_START_TOKEN) return 0; =20 - slow =3D lock_sock_fast(sk); + lock_sock(sk); =20 - if (unlikely(sk_unhashed(sk))) { + if (unlikely(sock_flag(sk, SOCK_DEAD))) { ret =3D SEQ_SKIP; goto unlock; } @@ -3749,7 +3748,7 @@ static int bpf_iter_unix_seq_show(struct seq_file *se= q, void *v) prog =3D bpf_iter_get_info(&meta, false); ret =3D unix_prog_seq_show(prog, &meta, v, uid); unlock: - unlock_sock_fast(sk, slow); + release_sock(sk); return ret; } =20 --=20 2.53.0 From nobody Thu Apr 23 10:30:52 2026 Received: from mailtransmit04.runbox.com (mailtransmit04.runbox.com [185.226.149.37]) (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 99ADE3C13F9; Tue, 14 Apr 2026 14:14:03 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=185.226.149.37 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776176046; cv=none; b=uIbgMPMY8t9PKU8mov+XEzM9DziTFLUdNCiL3KQBMWgD2XLF3mU3lRuZr+C6h5+KFtw1SmhjaMhGMLoIi0tH5GsDQPebKjqhE+1wI3EG8/nhV/fVh4WJWTKg4xXnc+xDuMZVPHlyTqdW+OSFbR1BDAKqDl2j0GhJ8xKqvhF+fBQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776176046; c=relaxed/simple; bh=Tz5h4ysCy2wr77Qnz7wSJx6KWOsFG8dDm3YYaFhM24U=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=d8eg7Zxvu5qntKFtbsoAGVzCvwf/+o2Iz6wahuaWojQUarXjfG43JwgG8gCUs7AiMpCsv2+J5Dj2skVSzpUGDD6HJNlpZEU09LKHuUNzkYBYXGKrYFJhYSELtH7RbG3l893lLKEfRO2UVxY7ePPn8D6zjbuAKh6pOCeEncThdOo= 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=ECnfTSB0; arc=none smtp.client-ip=185.226.149.37 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="ECnfTSB0" Received: from mailtransmit02.runbox ([10.9.9.162] helo=aibo.runbox.com) by mailtransmit04.runbox.com with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.93) (envelope-from ) id 1wCeWK-00FB5K-H0; Tue, 14 Apr 2026 16:13:40 +0200 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=rbox.co; s=selector1; h=Cc:To:In-Reply-To:References:Message-Id: Content-Transfer-Encoding:Content-Type:MIME-Version:Subject:Date:From; bh=k0G6DZFxuXzBdBD0yGiDWDu5betWefJe5EZr40nlZbo=; b=ECnfTSB0iwQd3K1wyBC85TUEEj bjAM6l+NVyDavLcjENB2pVRUEnRCjuV27U1CTHeZvN9gZX5UPhKwEnkdlnyb2x8nzlRtANUe9kzk4 Di5jjhk4wtQa4WDzohyk07134naA+7yaDJWi+H6zpaWcomaRhU7MQ3/Z1//+bIf/tI2J3nDOAvM7r 7A/XNBbK6HzSGbm4bEYAmCa4lXtqqhDRWmeCtsD4s3gatdfrVVXGt67U2PAL/x7XAgFWH1nN41EZn cKu5bRiHfoj6LCaH0JSF92jzxxgydhdpzwnfj+DM0IG6FXsfWw/1EoJip8Tvo1g8KFTo2lxTBk4xv dmbFJ5GA==; Received: from [10.9.9.72] (helo=submission01.runbox) by mailtransmit02.runbox with esmtp (Exim 4.86_2) (envelope-from ) id 1wCeWK-0000UZ-6J; Tue, 14 Apr 2026 16:13:40 +0200 Received: by submission01.runbox with esmtpsa [Authenticated ID (604044)] (TLS1.2:ECDHE_SECP256R1__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) (Exim 4.93) id 1wCeWC-00DhbX-SV; Tue, 14 Apr 2026 16:13:32 +0200 From: Michal Luczaj Date: Tue, 14 Apr 2026 16:13:17 +0200 Subject: [PATCH bpf v4 3/5] selftests/bpf: Extend bpf_iter_unix to attempt deadlocking Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <20260414-unix-proto-update-null-ptr-deref-v4-3-2af6fe97918e@rbox.co> References: <20260414-unix-proto-update-null-ptr-deref-v4-0-2af6fe97918e@rbox.co> In-Reply-To: <20260414-unix-proto-update-null-ptr-deref-v4-0-2af6fe97918e@rbox.co> To: 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, Michal Luczaj , Jiayuan Chen X-Mailer: b4 0.15.2 Updating a sockmap from a unix iterator prog may lead to a deadlock. Piggyback on the original selftest. Reviewed-by: Jiayuan Chen Signed-off-by: Michal Luczaj Reviewed-by: Kuniyuki Iwashima --- tools/testing/selftests/bpf/progs/bpf_iter_unix.c | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/tools/testing/selftests/bpf/progs/bpf_iter_unix.c b/tools/test= ing/selftests/bpf/progs/bpf_iter_unix.c index fea275df9e22..a2652c8c3616 100644 --- a/tools/testing/selftests/bpf/progs/bpf_iter_unix.c +++ b/tools/testing/selftests/bpf/progs/bpf_iter_unix.c @@ -7,6 +7,13 @@ =20 char _license[] SEC("license") =3D "GPL"; =20 +SEC(".maps") struct { + __uint(type, BPF_MAP_TYPE_SOCKMAP); + __uint(max_entries, 1); + __type(key, __u32); + __type(value, __u64); +} sockmap; + static long sock_i_ino(const struct sock *sk) { const struct socket *sk_socket =3D sk->sk_socket; @@ -76,5 +83,8 @@ int dump_unix(struct bpf_iter__unix *ctx) =20 BPF_SEQ_PRINTF(seq, "\n"); =20 + /* Test for deadlock. */ + bpf_map_update_elem(&sockmap, &(int){0}, sk, 0); + return 0; } --=20 2.53.0 From nobody Thu Apr 23 10:30:52 2026 Received: from mailtransmit04.runbox.com (mailtransmit04.runbox.com [185.226.149.37]) (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 A40F013D891; Tue, 14 Apr 2026 14:28:10 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=185.226.149.37 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776176893; cv=none; b=jUoA94/cZRmz1uYBLYLBBpCuncxruInG7qNUKhSGTugrWKuu2QgiMTscH7R4wXpPiJbIiKC2uYU1dlgLDkcMobV6PPL9PRyesVI20pMm1uHip8nFETuNiETP2Jrap+nDLfDpDZan8bHVAbXP+q+7Vu8/6MjOuijM6PN4wZHfVkQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776176893; c=relaxed/simple; bh=p8Zy4nEBkR+9ygIdN12Yw4cEGuBqrwNG0zv+nsgBx1Y=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=TVe5WMhvnnu2uasAPZNLy2TPp6K1opV2uKgiQvwNNL9q4mCEvHQCO+vDInYGNlb5t+5bj9q7Qny/MBOVGcAewREKgwSxrj4Y8HvgZgSGdM7gfuUwn++cv6xPTdaxe6rK5TtZTr829kkUPw1Y6oC/+hiFGiA8zhf41zPrSVWCx9g= 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=I6KproVw; arc=none smtp.client-ip=185.226.149.37 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="I6KproVw" Received: from mailtransmit03.runbox ([10.9.9.163] helo=aibo.runbox.com) by mailtransmit04.runbox.com with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.93) (envelope-from ) id 1wCeWJ-00FB59-OP; Tue, 14 Apr 2026 16:13:39 +0200 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=rbox.co; s=selector1; h=Cc:To:In-Reply-To:References:Message-Id: Content-Transfer-Encoding:Content-Type:MIME-Version:Subject:Date:From; bh=X2qj25w98WiHnwStskIYNOIACWJIKBz1Po4lV2H/JLA=; b=I6KproVwiOhp3VkHnpZ4puOYjM jKpsGVpJbMxuZqvrxuHCMXyXTQfaKrPISdyNIQRYV9QMuHwyJ6Ghdg6G8a1akSCYg1+ufMdLCZp2Z UIilcls5V1RJJ4R+B79hmzYUk9uZxU/Xb1uvuuWqSDmOjWPmZEfDUYgrf8aKzn3pXLevKjmnXvc3B dLIYQU1/ExoUVMtumBvM/yeMVU5SmJoosBwO5ZYXjqZYncQwBfHuBDVxTQLggP8pkOk0mSC7JQtlN CPLJPm5Nusx1R+o0y4n3z5IFzbyvGi/KFHkTYRlyg6P2c1037Nx4I+e8KXQVUo86ZLVCiDNeVnDdn 9bg+S5jQ==; Received: from [10.9.9.72] (helo=submission01.runbox) by mailtransmit03.runbox with esmtp (Exim 4.86_2) (envelope-from ) id 1wCeWI-0001rb-Ku; Tue, 14 Apr 2026 16:13:38 +0200 Received: by submission01.runbox with esmtpsa [Authenticated ID (604044)] (TLS1.2:ECDHE_SECP256R1__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) (Exim 4.93) id 1wCeWE-00DhbX-8g; Tue, 14 Apr 2026 16:13:34 +0200 From: Michal Luczaj Date: Tue, 14 Apr 2026 16:13:18 +0200 Subject: [PATCH bpf v4 4/5] bpf, sockmap: Fix af_unix null-ptr-deref in proto update Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <20260414-unix-proto-update-null-ptr-deref-v4-4-2af6fe97918e@rbox.co> References: <20260414-unix-proto-update-null-ptr-deref-v4-0-2af6fe97918e@rbox.co> In-Reply-To: <20260414-unix-proto-update-null-ptr-deref-v4-0-2af6fe97918e@rbox.co> To: 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, Michal Luczaj , =?utf-8?q?=E9=92=B1=E4=B8=80=E9=93=AD?= X-Mailer: b4 0.15.2 unix_stream_connect() sets sk_state (`WRITE_ONCE(sk->sk_state, TCP_ESTABLISHED)`) _before_ it assigns a peer (`unix_peer(sk) =3D newsk`). sk_state =3D=3D TCP_ESTABLISHED makes sock_map_sk_state_allowed() believe t= hat socket is properly set up, which would include having a defined peer. IOW, there's a window when unix_stream_bpf_update_proto() can be called on socket which still has unix_peer(sk) =3D=3D NULL. CPU0 bpf CPU1 connect -------- ------------ WRITE_ONCE(sk->sk_state, TCP_ESTABLISHED) sock_map_sk_state_allowed(sk) ... sk_pair =3D unix_peer(sk) sock_hold(sk_pair) sock_hold(newsk) smp_mb__after_atomic() unix_peer(sk) =3D newsk BUG: kernel NULL pointer dereference, address: 0000000000000080 RIP: 0010:unix_stream_bpf_update_proto+0xa0/0x1b0 Call Trace: sock_map_link+0x564/0x8b0 sock_map_update_common+0x6e/0x340 sock_map_update_elem_sys+0x17d/0x240 __sys_bpf+0x26db/0x3250 __x64_sys_bpf+0x21/0x30 do_syscall_64+0x6b/0x3a0 entry_SYSCALL_64_after_hwframe+0x76/0x7e Initial idea was to move peer assignment _before_ the sk_state update[1], but that involved an additional memory barrier, and changing the hot path was rejected. Then a NULL check during proto update in unix_stream_bpf_update_proto() was considered[2], but the follow-up discussion[3] focused on the root cause, i.e. sockmap update taking a wrong lock. Or, more specifically, missing unix_state_lock()[4]. In the end it was concluded that teaching sockmap about the af_unix locking would be unnecessarily complex[5]. Complexity aside, since BPF_PROG_TYPE_SCHED_CLS and BPF_PROG_TYPE_SCHED_ACT are allowed to update sockmaps, sock_map_update_elem() taking the unix lock, as it is currently implemented in unix_state_lock(): spin_lock(&unix_sk(s)->lock), would be problematic. unix_state_lock() taken in a process context, followed by a softirq-context TC BPF program attempting to take the same spinlock -- deadlock[6]. This way we circled back to the peer check idea[2]. [1]: https://lore.kernel.org/netdev/ba5c50aa-1df4-40c2-ab33-a72022c5a32e@rb= ox.co/ [2]: https://lore.kernel.org/netdev/20240610174906.32921-1-kuniyu@amazon.co= m/ [3]: https://lore.kernel.org/netdev/7603c0e6-cd5b-452b-b710-73b64bd9de26@li= nux.dev/ [4]: https://lore.kernel.org/netdev/CAAVpQUA+8GL_j63CaKb8hbxoL21izD58yr1Nvh= OhU=3Dj+35+3og@mail.gmail.com/ [5]: https://lore.kernel.org/bpf/CAAVpQUAHijOMext28Gi10dSLuMzGYh+jK61Ujn+fZ= -wvcODR2A@mail.gmail.com/ [6]: https://lore.kernel.org/bpf/dd043c69-4d03-46fe-8325-8f97101435cf@linux= .dev/ Summary of scenarios where af_unix/stream connect() may race a sockmap update: 1. connect() vs. bpf(BPF_MAP_UPDATE_ELEM), i.e. sock_map_update_elem_sys() Implemented NULL check is sufficient. Once assigned, socket peer won't be released until socket fd is released. And that's not an issue because sock_map_update_elem_sys() bumps fd refcnf. 2. connect() vs BPF program doing update Update restricted per verifier.c:may_update_sockmap() to BPF_PROG_TYPE_TRACING/BPF_TRACE_ITER BPF_PROG_TYPE_SOCK_OPS (bpf_sock_map_update() only) BPF_PROG_TYPE_SOCKET_FILTER BPF_PROG_TYPE_SCHED_CLS BPF_PROG_TYPE_SCHED_ACT BPF_PROG_TYPE_XDP BPF_PROG_TYPE_SK_REUSEPORT BPF_PROG_TYPE_FLOW_DISSECTOR BPF_PROG_TYPE_SK_LOOKUP Plus one more race to consider: CPU0 bpf CPU1 connect -------- ------------ WRITE_ONCE(sk->sk_state, TCP_ESTABLISHED) sock_map_sk_state_allowed(sk) sock_hold(newsk) smp_mb__after_atomic() unix_peer(sk) =3D newsk sk_pair =3D unix_peer(sk) if (unlikely(!sk_pair)) return -EINVAL; CPU1 close ---------- skpair =3D unix_peer(sk); unix_peer(sk) =3D NULL; sock_put(skpair) // use after free? sock_hold(sk_pair) 2.1 BPF program invoking helper function bpf_sock_map_update() -> BPF_CALL_4(bpf_sock_map_update(), ...) Helper limited to BPF_PROG_TYPE_SOCK_OPS. Nevertheless, a unix sock might be accessible via bpf_map_lookup_elem(). Which implies sk already having psock, which in turn implies sk already having sk_pair. Since sk_psock_destroy() is queued as RCU work, sk_pair won't go away while BPF executes the update. 2.2 BPF program invoking helper function bpf_map_update_elem() -> sock_map_update_elem() 2.2.1 Unix sock accessible to BPF prog only via sockmap lookup in BPF_PROG_TYPE_SOCKET_FILTER, BPF_PROG_TYPE_SCHED_CLS, BPF_PROG_TYPE_SCHED_ACT, BPF_PROG_TYPE_XDP, BPF_PROG_TYPE_SK_REUSEPORT, BPF_PROG_TYPE_FLOW_DISSECTOR, BPF_PROG_TYPE_SK_LOOKUP. Pretty much the same as case 2.1. 2.2.2 Unix sock accessible to BPF program directly: BPF_PROG_TYPE_TRACING, narrowed down to BPF_TRACE_ITER. Sockmap iterator (sock_map_seq_ops) is safe: unix sock residing in a sockmap means that the sock already went through the proto update step. Unix sock iterator (bpf_iter_unix_seq_ops), on the other hand, gives access to socks that may still be unconnected. Which means iterator prog can race sockmap/proto update against connect(). BUG: KASAN: null-ptr-deref in unix_stream_bpf_update_proto+0x2= 53/0x4d0 Write of size 4 at addr 0000000000000080 by task test_progs/31= 40 Call Trace: dump_stack_lvl+0x5d/0x80 kasan_report+0xe4/0x1c0 kasan_check_range+0x125/0x200 unix_stream_bpf_update_proto+0x253/0x4d0 sock_map_link+0x71c/0xec0 sock_map_update_common+0xbc/0x600 sock_map_update_elem+0x19a/0x1f0 bpf_prog_bbbf56096cdd4f01_selective_dump_unix+0x20c/0x217 bpf_iter_run_prog+0x21e/0xae0 bpf_iter_unix_seq_show+0x1e0/0x2a0 bpf_seq_read+0x42c/0x10d0 vfs_read+0x171/0xb20 ksys_read+0xff/0x200 do_syscall_64+0xf7/0x5e0 entry_SYSCALL_64_after_hwframe+0x76/0x7e While the introduced NULL check prevents null-ptr-deref in the BPF program path as well, it is insufficient to guard against a poorly timed close() leading to a use-after-free. This will be addressed in a subsequent patch. Reported-by: Michal Luczaj Closes: https://lore.kernel.org/netdev/ba5c50aa-1df4-40c2-ab33-a72022c5a32e= @rbox.co/ Reported-by: =E9=92=B1=E4=B8=80=E9=93=AD Suggested-by: Kuniyuki Iwashima Suggested-by: Martin KaFai Lau Fixes: c63829182c37 ("af_unix: Implement ->psock_update_sk_prot()") Signed-off-by: Michal Luczaj Reviewed-by: Kuniyuki Iwashima --- net/unix/unix_bpf.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/net/unix/unix_bpf.c b/net/unix/unix_bpf.c index e0d30d6d22ac..57f3124c9d8d 100644 --- a/net/unix/unix_bpf.c +++ b/net/unix/unix_bpf.c @@ -185,6 +185,9 @@ int unix_stream_bpf_update_proto(struct sock *sk, struc= t sk_psock *psock, bool r */ if (!psock->sk_pair) { sk_pair =3D unix_peer(sk); + if (unlikely(!sk_pair)) + return -EINVAL; + sock_hold(sk_pair); psock->sk_pair =3D sk_pair; } --=20 2.53.0 From nobody Thu Apr 23 10:30:52 2026 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 4549A3E95A0; Tue, 14 Apr 2026 15:22:22 +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=1776180147; cv=none; b=BSXyLqMBEiw5IcRn9Wwhy2Nhbhfpl2etYr2stMciveQunIUjF4SN/umyBo9XEGBfTnYXzrsscrcZkBNrccz9jnUQ1tkfGTHTmlmjhIpmS87gGACscDVlCQDCq79s8s3G9R6b1urNYq/L+aK5zyNQz1n1NSRvVQ8dYLlKDV+uAMY= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776180147; c=relaxed/simple; bh=taFpJsD3cqIQOrfDn60ksBezLhwXN4BUzm+oTo6qMes=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=S7ScTmBMrWAFp64Si8SMXFGeBoyiP7gB11NntI1kUdG2YVZhrzsYOycChgq+oRLbJSUBu/bbe8LuSJiy+2/SEGW06edXqmxt4LzoGvCcw3viT5c6K0SGcLtuI2qixIilNPw3EeHZHLyCW4addwpAOF+VaGtVXjcx3saGVH6H/kk= 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=wMlkdLdy; 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="wMlkdLdy" 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 1wCeWL-00FdqA-Cx; Tue, 14 Apr 2026 16:13:41 +0200 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=rbox.co; s=selector1; h=Cc:To:In-Reply-To:References:Message-Id: Content-Transfer-Encoding:Content-Type:MIME-Version:Subject:Date:From; bh=4eT1He741IBIbbJ2jmi515EMC/YD4I27qYRlmYaD+Bo=; b=wMlkdLdytFjiDq4XynqAPmggfN OknHwajgelQAKtjdqwm38RwDRn3oVGeup/b36BGlYufvwIZ7aRZzB3KH/V6vh1uXRQsU5NubiUFFZ BXcAlO7LwlQAqP24AYRNbx33oO8d7LuIHugLDBYkeNaGQuFBvBOi9f3qt1Fz8M461WSBcyhujY0Yp PWpzpUYu87OsiQeJ01+ssM2NPFOjeonOcSbNi1bhrVZnRVcmNpzY5PD8V78KroYsJsbdviOXhIsp1 Bd4CKvB96mud5vqejnFe5djIHJSMb68MwfAq4+np+EqFn4XbjcW/J7QRng8T/wvaYS7INf5bZcfG2 TN0+k61Q==; Received: from [10.9.9.72] (helo=submission01.runbox) by mailtransmit02.runbox with esmtp (Exim 4.86_2) (envelope-from ) id 1wCeWL-0000Uf-1x; Tue, 14 Apr 2026 16:13:41 +0200 Received: by submission01.runbox with esmtpsa [Authenticated ID (604044)] (TLS1.2:ECDHE_SECP256R1__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) (Exim 4.93) id 1wCeWF-00DhbX-Jw; Tue, 14 Apr 2026 16:13:35 +0200 From: Michal Luczaj Date: Tue, 14 Apr 2026 16:13:19 +0200 Subject: [PATCH bpf v4 5/5] bpf, sockmap: Take state lock for af_unix iter Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <20260414-unix-proto-update-null-ptr-deref-v4-5-2af6fe97918e@rbox.co> References: <20260414-unix-proto-update-null-ptr-deref-v4-0-2af6fe97918e@rbox.co> In-Reply-To: <20260414-unix-proto-update-null-ptr-deref-v4-0-2af6fe97918e@rbox.co> To: 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, Michal Luczaj X-Mailer: b4 0.15.2 When a BPF iterator program updates a sockmap, there is a race condition in unix_stream_bpf_update_proto() where the `peer` pointer can become stale[1] during a state transition TCP_ESTABLISHED -> TCP_CLOSE. CPU0 bpf CPU1 close -------- ---------- // unix_stream_bpf_update_proto() sk_pair =3D unix_peer(sk) if (unlikely(!sk_pair)) return -EINVAL; // unix_release_sock() skpair =3D unix_peer(sk); unix_peer(sk) =3D NULL; sock_put(skpair) sock_hold(sk_pair) // UaF More practically, this fix guarantees that the iterator program is consistently provided with a unix socket that remains stable during iterator execution. [1]: BUG: KASAN: slab-use-after-free in unix_stream_bpf_update_proto+0x155/0x490 Write of size 4 at addr ffff8881178c9a00 by task test_progs/2231 Call Trace: dump_stack_lvl+0x5d/0x80 print_report+0x170/0x4f3 kasan_report+0xe4/0x1c0 kasan_check_range+0x125/0x200 unix_stream_bpf_update_proto+0x155/0x490 sock_map_link+0x71c/0xec0 sock_map_update_common+0xbc/0x600 sock_map_update_elem+0x19a/0x1f0 bpf_prog_bbbf56096cdd4f01_selective_dump_unix+0x20c/0x217 bpf_iter_run_prog+0x21e/0xae0 bpf_iter_unix_seq_show+0x1e0/0x2a0 bpf_seq_read+0x42c/0x10d0 vfs_read+0x171/0xb20 ksys_read+0xff/0x200 do_syscall_64+0xf7/0x5e0 entry_SYSCALL_64_after_hwframe+0x76/0x7e Allocated by task 2236: kasan_save_stack+0x30/0x50 kasan_save_track+0x14/0x30 __kasan_slab_alloc+0x63/0x80 kmem_cache_alloc_noprof+0x1d5/0x680 sk_prot_alloc+0x59/0x210 sk_alloc+0x34/0x470 unix_create1+0x86/0x8a0 unix_stream_connect+0x318/0x15b0 __sys_connect+0xfd/0x130 __x64_sys_connect+0x72/0xd0 do_syscall_64+0xf7/0x5e0 entry_SYSCALL_64_after_hwframe+0x76/0x7e Freed by task 2236: kasan_save_stack+0x30/0x50 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x70 __kasan_slab_free+0x47/0x70 kmem_cache_free+0x11c/0x590 __sk_destruct+0x432/0x6e0 unix_release_sock+0x9b3/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+0xf7/0x5e0 entry_SYSCALL_64_after_hwframe+0x76/0x7e Suggested-by: Kuniyuki Iwashima Fixes: 2c860a43dd77 ("bpf: af_unix: Implement BPF iterator for UNIX domain = socket.") Signed-off-by: Michal Luczaj --- net/unix/af_unix.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/net/unix/af_unix.c b/net/unix/af_unix.c index 590a30d3b2f7..15b48cc6e9b0 100644 --- a/net/unix/af_unix.c +++ b/net/unix/af_unix.c @@ -3737,6 +3737,7 @@ static int bpf_iter_unix_seq_show(struct seq_file *se= q, void *v) return 0; =20 lock_sock(sk); + unix_state_lock(sk); =20 if (unlikely(sock_flag(sk, SOCK_DEAD))) { ret =3D SEQ_SKIP; @@ -3748,6 +3749,7 @@ static int bpf_iter_unix_seq_show(struct seq_file *se= q, void *v) prog =3D bpf_iter_get_info(&meta, false); ret =3D unix_prog_seq_show(prog, &meta, v, uid); unlock: + unix_state_unlock(sk); release_sock(sk); return ret; } --=20 2.53.0