From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mta0.migadu.com (out-249.mta0.migadu.com [91.218.175.249]) (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 D93B94457BA for ; Fri, 4 Sep 2026 09:50:22 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=91.218.175.249 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788515425; cv=none; b=uaNyCr3WjrmGZEO53gaLKT8TwlVD1r9QkMKVbfYFd11TxyVQuGYG9g5wYWxCIqW8PibMJzbkQFnWVFslRrVmpoXK+53W5/VRKKoR1iVbTUmAmLsOWWh7ycwCsHLpDmOQK/UyS5MoB3mM7WcVZVdoXiZAVQcSFP9Cheb6e/f0foQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788515425; c=relaxed/simple; bh=EAsMAvBTcviNBGAG81DhWph2becLaMvRGr2P16KnjLk=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=YkitIXm+276M1kBwAftBQIiZnRp7y/YNO+TQ5zeDUVNCvsm8c1AMpcQdhDvJpP3SfkoiOEoVxYGtpth8AnTq0qdj9z/3BliGNNpHwYr5IcQpZs1ryigJo0VRBoNKg89Fzao559c98Vsislqm7WXr0Yp4QxyEZbkpYX5CmPUgmLQ= 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=hI0JOXs3; arc=none smtp.client-ip=91.218.175.249 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="hI0JOXs3" X-Envelope-To: linux-kselftest@vger.kernel.org DKIM-Signature: a=rsa-sha256; bh=EAsMAvBTcviNBGAG81DhWph2becLaMvRGr2P16KnjLk=; c=simple/simple; d=linux.dev; h=from:to:subject:date:message-id:mime-version:content-type; s=key1; t=1788515421; v=1; x=1789120221; b=hI0JOXs3uMxMQVJrgE0SNTLtPhrfmIRjl4HidK2Spph9yifYvf0FQrJo/Tr+BkHVSge7/z+b EbFbkfKjr8wo3IXbzH8SNpuF3qVJVNKG19reNyqf081fJ54/MY5vKaFwHHrnzkTSztVWW5a5Myj fhEA6ppri1FYhNRq0HJ0fX2g= X-Envelope-To: linux-kselftest@vger.kernel.org Received: by smtp.migadu.com with ESMTPS id 32d6539a7a9261dc; Fri, 04 Sep 2026 09:50:20 +0000 X-Mizu-Trace-ID: 32d6539a7a9261dc X-Migadu-Flow: FLOW_OUT From: Jiayuan Chen To: bpf@vger.kernel.org Cc: Jiayuan Chen , Xiang Mei , Daniel Borkmann , John Fastabend , Stanislav Fomichev , Martin KaFai Lau , Alexei Starovoitov , Andrii Nakryiko , Eduard Zingerman , Kumar Kartikeya Dwivedi , Song Liu , Yonghong Song , Jiri Olsa , Emil Tsalapatis , Ihor Solodrai , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Simon Horman , Shuah Khan , Aditi Ghag , netdev@vger.kernel.org, linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org Subject: [PATCH bpf v2 1/2] bpf: Fix out-of-bounds read of sk_protocol in bpf_sock_destroy() Date: Fri, 4 Sep 2026 17:49:36 +0800 Message-ID: <20260904094954.63447-1-jiayuan.chen@linux.dev> X-Mailer: git-send-email 2.43.0 Precedence: bulk X-Mailing-List: linux-kselftest@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit sk_protocol lives in struct sock, not in struct sock_common. A timewait or request sock handed to bpf_sock_destroy() by the tcp iterator is neither, so reading sk->sk_protocol runs past the object: ================================================================== BUG: KASAN: slab-out-of-bounds in bpf_sock_destroy+0xc7/0xe0 Read of size 2 at addr ffff8881047d11b4 by task test_progs/428 Tainted: [W]=WARN Call Trace: dump_stack_lvl+0x91/0xf0 print_report+0xd1/0x630 kasan_report+0xf3/0x130 __asan_report_load2_noabort+0x14/0x30 bpf_sock_destroy+0xc7/0xe0 bpf_prog_c3dd61f9d9cd9f37_iter_tcp6_timewait+0x9f/0xb7 bpf_iter_run_prog+0x538/0xde0 bpf_iter_tcp_seq_show+0x26b/0x4b0 bpf_seq_read+0x424/0x1210 vfs_read+0x197/0xe40 ksys_read+0x119/0x240 __x64_sys_read+0x72/0xc0 x64_sys_call+0x647/0x27e0 do_syscall_64+0xe5/0x610 entry_SYSCALL_64_after_hwframe+0x76/0x7e Only check sk_protocol on full socks. tcp_abort() already knows how to deal with TIME_WAIT and NEW_SYN_RECV socks. Also fix the comment, it never matched the code. Fixes: 4ddbcb886268 ("bpf: Add bpf_sock_destroy kfunc") Reported-by: Xiang Mei (Microsoft) Closes: https://lore.kernel.org/bpf/20260702224519.800135-1-xmei5@asu.edu/ Signed-off-by: Jiayuan Chen --- A reviewer asked to add ENOENT to the list of errors in the comment. I'd rather not list what the handlers return, that can change any time, so the comment now says "EOPNOTSUPP, or whatever the protocol specific destroy handler returns". v1 -> v2: modify comment AND avoid flaky about selftest v1: https://lore.kernel.org/bpf/20260903125306.299943-1-jiayuan.chen@linux.dev/ --- net/core/filter.c | 13 +++++++++---- 1 file changed, 9 insertions(+), 4 deletions(-) diff --git a/net/core/filter.c b/net/core/filter.c index 61940e753552..a41cc60a401a 100644 --- a/net/core/filter.c +++ b/net/core/filter.c @@ -12912,8 +12912,9 @@ __bpf_kfunc_start_defs(); * @sock: Pointer to socket to be destroyed * * Return: - * On error, may return EPROTONOSUPPORT, EINVAL. - * EPROTONOSUPPORT if protocol specific destroy handler is not supported. + * On error, may return EOPNOTSUPP, or whatever the protocol specific + * destroy handler returns. + * EOPNOTSUPP if protocol specific destroy handler is not supported. * 0 otherwise */ __bpf_kfunc int bpf_sock_destroy(struct sock_common *sock) @@ -12925,8 +12926,12 @@ __bpf_kfunc int bpf_sock_destroy(struct sock_common *sock) * Supporting protocols will need to acquire sock lock in the BPF context * prior to invoking this kfunc. */ - if (!sk->sk_prot->diag_destroy || (sk->sk_protocol != IPPROTO_TCP && - sk->sk_protocol != IPPROTO_UDP)) + if (!sk->sk_prot->diag_destroy) + return -EOPNOTSUPP; + + if (sk_fullsock(sk) && + sk->sk_protocol != IPPROTO_TCP && + sk->sk_protocol != IPPROTO_UDP) return -EOPNOTSUPP; return sk->sk_prot->diag_destroy(sk, ECONNABORTED); -- 2.43.0