From: Michal Luczaj <mhal@rbox.co>
To: Martin KaFai Lau <martin.lau@linux.dev>,
Kuniyuki Iwashima <kuniyu@google.com>
Cc: John Fastabend <john.fastabend@gmail.com>,
Jakub Sitnicki <jakub@cloudflare.com>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Simon Horman <horms@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
netdev@vger.kernel.org, bpf@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH bpf] bpf, sockmap: Fix af_unix null-ptr-deref in proto update
Date: Tue, 3 Feb 2026 10:57:46 +0100 [thread overview]
Message-ID: <8d055903-fe44-4bbf-a1a5-e0176343bf0b@rbox.co> (raw)
In-Reply-To: <6de6f1bf-c8ee-4dfb-9b8c-f89185946630@linux.dev>
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_peer(sk)
> pointer, it should be fine. The unix_peer(sk) pointer is not a trusted
> 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
Call Trace:
dump_stack_lvl+0x5d/0x80
print_report+0x170/0x4f3
kasan_report+0xe1/0x180
bpf_skc_to_unix_sock+0x95/0xb0
bpf_prog_382743e45576abd5_dump_unix+0x4a0/0x576
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
Allocated by task 1941:
kasan_save_stack+0x30/0x50
kasan_save_track+0x14/0x30
__kasan_slab_alloc+0x63/0x80
kmem_cache_alloc_noprof+0x1f7/0x6f0
sk_prot_alloc+0x59/0x210
sk_alloc+0x34/0x470
unix_create1+0x86/0x8a0
unix_create+0xd4/0x2d0
__sock_create+0x243/0x5a0
__sys_socket+0x119/0x1d0
__x64_sys_socket+0x72/0xd0
do_syscall_64+0x6b/0x3a0
entry_SYSCALL_64_after_hwframe+0x76/0x7e
Freed by task 1941:
kasan_save_stack+0x30/0x50
kasan_save_track+0x14/0x30
kasan_save_free_info+0x3b/0x70
__kasan_slab_free+0x47/0x70
kmem_cache_free+0x12c/0x5d0
__sk_destruct+0x432/0x6e0
unix_release_sock+0x9b3/0xf60
unix_release_sock+0x99f/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+0x6b/0x3a0
entry_SYSCALL_64_after_hwframe+0x76/0x7e
next prev parent reply other threads:[~2026-02-03 9:57 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-29 16:47 [PATCH bpf] bpf, sockmap: Fix af_unix null-ptr-deref in proto update Michal Luczaj
2026-01-29 19:41 ` Martin KaFai Lau
2026-01-30 11:00 ` Michal Luczaj
2026-01-30 21:29 ` Martin KaFai Lau
2026-01-31 10:06 ` Kuniyuki Iwashima
2026-02-02 15:10 ` Michal Luczaj
2026-02-03 3:53 ` Martin KaFai Lau
2026-02-03 9:57 ` Michal Luczaj [this message]
2026-02-03 19:47 ` Kuniyuki Iwashima
2026-02-04 7:15 ` Martin KaFai Lau
2026-02-04 7:58 ` Kuniyuki Iwashima
2026-02-04 15:41 ` Michal Luczaj
2026-02-04 19:16 ` Kuniyuki Iwashima
2026-02-04 20:18 ` Martin KaFai Lau
2026-02-04 19:34 ` Martin KaFai Lau
2026-02-04 21:09 ` Kuniyuki Iwashima
2026-02-05 0:55 ` Martin KaFai Lau
2026-02-05 2:00 ` Martin KaFai Lau
2026-02-05 7:39 ` Kuniyuki Iwashima
2026-02-04 23:25 ` Michal Luczaj
2026-02-05 0:27 ` Kuniyuki Iwashima
2026-02-05 0:31 ` Martin KaFai Lau
2026-02-02 19:15 ` Martin KaFai Lau
2026-02-07 14:37 ` Michal Luczaj
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8d055903-fe44-4bbf-a1a5-e0176343bf0b@rbox.co \
--to=mhal@rbox.co \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=horms@kernel.org \
--cc=jakub@cloudflare.com \
--cc=john.fastabend@gmail.com \
--cc=kuba@kernel.org \
--cc=kuniyu@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=martin.lau@linux.dev \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox