From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-dy1-f176.google.com (mail-dy1-f176.google.com [74.125.82.176]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D57DE22339 for ; Wed, 4 Feb 2026 19:16:22 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=pass smtp.client-ip=74.125.82.176 ARC-Seal:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770232583; cv=pass; b=MgWss5+FL5tLmZShZA8O9S/NoFIzctStRtXWbZsxgW23w5c8XE9Y9/hVMkszpP+b3UAr43DMzqRVjhbkaOyWb730KYDc6rP9G1SBD5nqaqc3S0nzBmrPknkrV+qiiD7eMHny4TyyQFPjrJyow+p7FYRfMixctt6VxxPR+WdSP80= ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770232583; c=relaxed/simple; bh=PER2BQrsL1CJQhKWon9Mz9meNiPet/3DEkc6fa8mvI4=; h=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=ALSoKgFq0qZLEoMdBspRt3/OtbA93BacITL+a9loxvWWvJEieYYzxJVsv8QB8Jg6/aj8LuE8+1e7HyWzgGM64IacbUL0ER5y4ZZouosqAYQmfqZkvGK9ZiSunkRL1a4p9LtT1C9aqz9cWOv9twPoXWDlbHjhmqJgGH0GUPkUJb0= ARC-Authentication-Results:i=2; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=lOYWQFnd; arc=pass smtp.client-ip=74.125.82.176 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="lOYWQFnd" Received: by mail-dy1-f176.google.com with SMTP id 5a478bee46e88-2b834e17c3fso85258eec.0 for ; Wed, 04 Feb 2026 11:16:22 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1770232582; cv=none; d=google.com; s=arc-20240605; b=gySlP7bQ3T+5cwuQ3hIFEiFQlK4oMUUVukqptBmpPMg7sykFUzmYa4lcLHTe07Buo7 Ei1PiDDKfAi9W+T1QjwcMGzRYgonVVXC8K4PKMdvrYj5pGeIefA3/QPigZEywqXtATNj ajlGCF8nVSWZSzGGw7FPYUC6j5KKu5jUHa/iuZM8xJrHBTg4HdOWb2hRJ4cl5426U71M +sX+E3S4FF0JHcf9wwSWOSiDdjVdx3M+q2+t0J7XtolTgBAHZM9jpXcsPJVajU0jGdbH JNwgDKipBJroTVieBqiImgMoue7d/N63jH7I7LGTtEDfh8qi2onIcanExhd7txonEXqs GgvQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=3uHPEEWLcSxU31xZCU6niHg5YWDthT8oTTsiIIWluck=; fh=+XIojPcOtuA/9imTvTcRkq7Wv+Z6W6VCwlg+Z2nKibY=; b=gFZWsVvRan5ayqPzIL5xo5BpimvOUg6vDrXC06f/Ch2J3Mj7RY5bs8OOIL4rVCvB72 ONl9aWJJ64HXoJI+dy6noW1sjARidZwEnhqhDx/YmziI7GqinKh867eeuvQtWvt6XOKB 4bQIYwNSygwqwgM4GgqiMT/KuAi1FR+xZf1VmVphihgG98Ns5KeHbm8VNkypbMcAIMeZ LIm1aZreXeDBnCFmPPj2kYTg4uD2f4xIclu6ToFLJM7qK5ofFxlBfKGEZ4Z7+2aUYu4r u1dXim3qqVerT67OHmks7DkPUrylYVxvohOk9BTJKmIM/6+AZiU+QS5UeJIMO99SuBIG QaRg==; darn=vger.kernel.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1770232582; x=1770837382; darn=vger.kernel.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=3uHPEEWLcSxU31xZCU6niHg5YWDthT8oTTsiIIWluck=; b=lOYWQFndCQ/CnmrxHZybSqR1JZxpgUlCwKdSzfqTL9v3PN2DBu8h/ZtFI9kle8waoi CD9ts7V9/6II5LjcouyoAiFgjm9idk1hyxcBJ19hdmdS4etLs9cM3Wk3Lw4v6lpaXEzK WMFz6LChoLmTVv5JTBmdy8LqEYLhjuqrJNODuH36BQcimdXe3flrt0VSK1UJvlACVfFF J8zGLZYXoyQ1sQlPe8UJ6ga8x2aWn4au6h0br53kGLRp3/96D2CPuBskbJdZLpnc6Xg6 ouoOg70PKzSIHXnp37KEdtkWUjWrCOMwYXoFstNe0PhXhWZyvNZ0Y777gLjR2kXrtVgU wixg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1770232582; x=1770837382; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=3uHPEEWLcSxU31xZCU6niHg5YWDthT8oTTsiIIWluck=; b=YnQuIipI6/fM8Nk/WQ/IMIOquO+/b46soulGFd+c3coIgOKeNJKrvpxuTDEKE3SCfK 70/cFPMnJmwVsDKbaUy/S5wqei96S+yXeM2bJ/Ap2olNholqrbfRiilaauqop3fVI8Mi g6zjkQN5R8K3o0OU2wozUM+BgOfuOrw4LQgPmxOjJeHnMeHPXgunX9vWZhIln6J8LPVN 1LRtOIrEcpVc+Cug7ktgBiLRSK0YX5dCkl0tdBVCMAn+shTAZuPuSmSFzLUNN4SPc9c+ 8FCpBO3SuhTZtSl/5qraOKM1aszGWsj++rWRnzDRv53leFysm7o66WHTkDVAckIPsQ8M /Flg== X-Forwarded-Encrypted: i=1; AJvYcCVLGMiDQ8ZDKkxxV8OGvpIZycA4y3Be3pmHgOtPfo6Xr9f7r+xAroUY2Zy0+7ODfYNZVqrtSXHoZNIUVJQ=@vger.kernel.org X-Gm-Message-State: AOJu0YybugjjAaR7OOqbRnrwI8QA8KLbF899OE77m3lTP62Z8yRBwCeB twtA2ZCq/4oq5D6WlCCbdNc+WKPUjb3HQfrjfMiTYMEG9QxTQQB9CKMK/QB6mOXAPkOiCsqqEtN tMRY/xDbP8WQvJ9WqYYVtMSiFv86VDxA0PaZnm4PV X-Gm-Gg: AZuq6aKiOvSQgTUPRopVQ/ZV37FgrnkIIm3d5Lv/tZLy7E0KnnJpcxvYSrI3Rm08urR C0zJac1s16H6aKT8yB9fD+E9laOYWbcsR74eo5K5SQndCWgOFod6CvkJRZCYK8YzEqmQdEmVM/U Vva4RPibWuD48flPLfVAMEr7xszf0opBpXVQ/0wvgNA7mXYnQPwJzCL2YEecNl9yY+AW2VUwBMU grt1XQF81w5It3wwRCIpC4pEt8+sVV/+eJTrqfyySdI0Msi4dK9j4qcyycxYG1hKBBMaQtj71j7 THbqjQeKmiQJLW4AZyJRXzgioHdjv643+08Wfzo6USPLg9wSepAbhy1RsBk4bON118s= X-Received: by 2002:a05:7300:534f:b0:2b7:f12:9503 with SMTP id 5a478bee46e88-2b83299d898mr1345406eec.30.1770232581601; Wed, 04 Feb 2026 11:16:21 -0800 (PST) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 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> In-Reply-To: <408569e7-2b82-4eff-b767-79ce6ef6cae0@rbox.co> From: Kuniyuki Iwashima Date: Wed, 4 Feb 2026 11:16:10 -0800 X-Gm-Features: AZwV_Qgur5lVdyr6ufrZv78YuIEfQq3BMw2wq875R33oIJICWlo4lt09ETOastQ Message-ID: Subject: Re: [PATCH bpf] bpf, sockmap: Fix af_unix null-ptr-deref in proto update To: Michal Luczaj Cc: Martin KaFai Lau , 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 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Feb 4, 2026 at 7:41=E2=80=AFAM Michal Luczaj wrote: > > On 2/4/26 08:58, Kuniyuki Iwashima wrote: > > On Tue, Feb 3, 2026 at 11:15=E2=80=AFPM Martin KaFai Lau wrote: > >> > >> On 2/3/26 11:47 AM, Kuniyuki Iwashima wrote: > >>> From: Michal Luczaj > >>> Date: Tue, 3 Feb 2026 10:57:46 +0100 > >>>> On 2/3/26 04:53, Martin KaFai Lau wrote: > >>>>> On 2/2/26 7:10 AM, Michal Luczaj wrote: > >>>>>> 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_pee= r(sk) > >>>>> pointer, it should be fine. The unix_peer(sk) pointer is not a trus= ted > >>>>> 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 > >> > >> hmm... bpf_skc_to_unix_sock is exposed to tracing. bpf_iter is a traci= ng > >> bpf prog. > >> > >>> > >>> Can you cook a patch for this ? probably like below > >> > >> This can help the bpf_iter but not the other tracing prog such as fent= ry. > > > > Oh well ... then bpf_skc_to_unix_sock() can be used even > > with SEQ_START_TOKEN at fentry of bpf_iter_unix_seq_show() ?? > > > > How about adding notrace to all af_unix bpf iterator functions ? > > > > The procfs iterator holds a spinlock of the hashtable from > > ->start/next() to ->stop() to prevent the race with unix_release_sock()= . > > > > I think other (non-iterator) functions cannot do such racy > > access with tracing prog. > > 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. Ah I was only considering SOCK_STREAM :p Only solution that came to mind is breaking change enforcing a release function to bpf_skc_to_unix_sock() so that it can hold the peer's refcnt and save the pointer somewhere else until the release function, but I think this is unacceptable. Also, I guess this type of issue could be triggered with any objects that are not refcounted by bpf tracing prog ? For example, inet_sock(sk)->inet_opt could be freed by setsockopt(IP_OPTIONS) even after fentry prog verifies that it's not NULL. I'm not sure if bpf_core_cast() etc allows such access, but if it's allowed, I think there is no general solution. Fortunately that's not null-deref nor oob-write, and it just reads stale info as Martin mentioned... so probably this is WAI for tracing prog ? > > 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 > > > > >> > >>> > >>> ---8<--- > >>> diff --git a/net/unix/af_unix.c b/net/unix/af_unix.c > >>> index 02ebad6afac7..9c7e9fbde362 100644 > >>> --- a/net/unix/af_unix.c > >>> +++ b/net/unix/af_unix.c > >>> @@ -3740,8 +3740,9 @@ static int bpf_iter_unix_seq_show(struct seq_fi= le *seq, void *v) > >>> return 0; > >>> > >>> slow =3D lock_sock_fast(sk); > >>> + unix_state_lock(sk); > >>> > >>> - if (unlikely(sk_unhashed(sk))) { > >>> + if (unlikely(sock_flag(other, SOCK_DEAD))) { > >>> ret =3D SEQ_SKIP; > >>> goto unlock; > >>> } > >>> @@ -3751,6 +3752,7 @@ static int bpf_iter_unix_seq_show(struct seq_fi= le *seq, void *v) > >>> prog =3D bpf_iter_get_info(&meta, false); > >>> ret =3D unix_prog_seq_show(prog, &meta, v, uid); > >>> unlock: > >>> + unix_staet_unlock(sk); > >>> unlock_sock_fast(sk, slow); > >>> return ret; > >>> } > >>> ---8<--- > >>> > >>> Thanks! > >> >