From: Lin Jiapeng <ljp1205831794@gmail.com>
To: netdev-bot+sinfo@kernel.org
Cc: Eric Dumazet <edumazet@kernel.org>,
Kuniyuki Iwashima <kuniyu@google.com>,
Paolo Abeni <pabeni@redhat.com>,
Willem de Bruijn <willemb@google.com>,
"David S. Miller" <davem@davemloft.net>,
Jakub Kicinski <kuba@kernel.org>, Simon Horman <horms@kernel.org>,
Martin KaFai Lau <kafai@fb.com>,
Daniel Borkmann <daniel@iogearbox.net>,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
TencentOS Corvus AI <corvus@tencent.com>,
stable@vger.kernel.org, Lin Jiapeng <jiapenglin@tencent.com>
Subject: Re: [PATCH net] net: reuseport: avoid duplicate closed socket insertion
Date: Fri, 6 Nov 2026 22:55:10 +0800 [thread overview]
Message-ID: <4c5e04a6-afba-4f7e-b790-c109ddad0318@gmail.com> (raw)
In-Reply-To: <179397371960.488859.17332481477084448537@kernel.org>
On 2026-11-06 10:01 p.m., netdev-bot+sinfo@kernel.org wrote:
> Hi!
>
> This is an automated message. This series looks like a fix, but its
> commit messages seem to be missing some information:
>
> - Whether the issue was actually triggered, or is only theoretical
> (e.g. found by code inspection). If it was triggered please include
> the symptoms, like the stack trace or error messages.
>
> Please do not repost the series just to address the above. Instead,
> reply to this email with the missing information, so that reviewers
> can take it into account. If the series needs another revision for
> other reasons, please include the information in the commit messages
> then.
>
> The evaluation is done by an LLM so it may be wrong, if you think
> that is the case please reply and explain.
The issue was actually triggered, not found by code inspection.
Reproducer outline (unprivileged, uid 65534, inside a fresh user + network
namespace with net.ipv4.tcp_migrate_req = 1):
1. Create two TCP listeners in the same SO_REUSEPORT group (one is kept
hashed as an anchor).
2. setsockopt(SO_REUSEPORT, 0) on one listener: sk_reuseport is cleared
but sk_reuseport_cb stays attached.
3. Repeat connect(AF_UNSPEC) + listen() 129 times on that socket. Each
disconnect goes through inet_unhash() -> reuseport_stop_listen_sock(),
which re-inserts the same socket into the closed section until
num_closed_socks exceeds max_socks.
4. The 129th insertion writes socks[-1], which overlaps reuse->prog on
x86_64. Attaching a classic BPF filter with SO_ATTACH_REUSEPORT_CBPF
on the other socket then consumes the struct sock pointer stored in
reuse->prog as a struct bpf_prog *.
Kernel: v7.4-rc1 based tree (d68ce4e71248), x86_64, CONFIG_KASAN=y,
CONFIG_UBSAN_BOUNDS=y, QEMU.
Symptoms, first the out-of-bounds write itself:
UBSAN: array-index-out-of-bounds in net/core/sock_reuseport.c:152:9
index -1 is out of range for type 'struct sock *[]
__counted_by(max_socks)'
CPU: 0 UID: 65534 PID: 22 Comm: poc
Call Trace:
__ubsan_handle_out_of_bounds+0x91/0xa0
reuseport_stop_listen_sock+0x290/0x310
inet_unhash+0xd5/0x400
tcp_set_state+0x125/0x260
tcp_disconnect+0x47/0x1950
__inet_stream_connect+0x2d0/0xab0
__x64_sys_connect+0x71/0x80
then, after SO_ATTACH_REUSEPORT_CBPF is issued on the second listener, the
corrupted prog pointer reaches the RCU free path as a struct sock *:
Oops: general protection fault, probably for non-canonical address
0xdffffc000000008e: 0000 [#1] KASAN
KASAN: null-ptr-deref in range [0x0000000000000470-0x0000000000000477]
RIP: 0010:call_rcu+0x10d/0x260
Call Trace:
? reuseport_attach_prog+0x6c/0x140
reuseport_attach_prog+0xdd/0x140
sk_reuseport_attach_filter+0x97/0xf0
sk_setsockopt+0x973/0x1cc0
__x64_sys_setsockopt+0xac/0xc0
followed by "Kernel panic - not syncing: Fatal exception".
With the proposed fix applied, the same reproducer completes cleanly: no
UBSAN report, no oops, the SO_ATTACH_REUSEPORT_CBPF call and socket
teardown all succeed, PoC exits 0.
I can share the reproducer program if that is useful.
next prev parent reply other threads:[~2026-11-06 14:55 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-06 13:58 [PATCH net] net: reuseport: avoid duplicate closed socket insertion Lin Jiapeng
2026-11-06 14:01 ` netdev-bot+sinfo
2026-11-06 14:55 ` Lin Jiapeng [this message]
2026-11-07 5:02 ` Jiayuan Chen
2026-11-07 8:08 ` Lin Jiapeng
2026-11-07 19:37 ` Kuniyuki Iwashima
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=4c5e04a6-afba-4f7e-b790-c109ddad0318@gmail.com \
--to=ljp1205831794@gmail.com \
--cc=corvus@tencent.com \
--cc=daniel@iogearbox.net \
--cc=davem@davemloft.net \
--cc=edumazet@kernel.org \
--cc=horms@kernel.org \
--cc=jiapenglin@tencent.com \
--cc=kafai@fb.com \
--cc=kuba@kernel.org \
--cc=kuniyu@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev-bot+sinfo@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=stable@vger.kernel.org \
--cc=willemb@google.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.