[PATCH net] net: reuseport: avoid duplicate closed socket insertion

[PATCH net] net: reuseport: avoid duplicate closed socket insertion

[Lin Jiapeng]

Clearing SO_REUSEPORT on a TCP listener clears sk_reuseport but leaves
sk_reuseport_cb attached to its reuseport group. A subsequent listen()
does not put the socket back into the listening section because
inet_hash() checks sk_reuseport. However, inet_unhash() checks
sk_reuseport_cb and calls reuseport_stop_listen_sock().

With request migration enabled, reuseport_stop_listen_sock() ignores
whether __reuseport_detach_sock() actually removed the socket from the
listening section and unconditionally appends it to the closed section.
Repeated connect(AF_UNSPEC)/listen() cycles therefore insert the same
socket until num_closed_socks exceeds max_socks. The next insertion
writes before socks[], overlapping prog on x86-64 and leading to type
confusion when a reuseport program is attached or detached.

Only insert the socket into the closed section when it was actually
removed from the listening section. A socket that was not rehashed as a
listener is already represented in the closed section, so leaving it
there preserves request migration semantics and prevents duplicate
entries and the resulting negative array indices.

Fixes: 333bb73f620e1 ("tcp: Keep TCP_CLOSE sockets in the reuseport group.")
Reported-by: TencentOS Corvus AI <corvus@tencent.com>
Cc: stable@vger.kernel.org
Signed-off-by: Lin Jiapeng <jiapenglin@tencent.com>
---
 net/core/sock_reuseport.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/net/core/sock_reuseport.c b/net/core/sock_reuseport.c
index fccbdd0430b0..775f446516c3 100644
--- a/net/core/sock_reuseport.c
+++ b/net/core/sock_reuseport.c
@@ -480,8 +480,8 @@ void reuseport_stop_listen_sock(struct sock *sk)
 			 */
 			bpf_sk_reuseport_detach(sk);
 
-			__reuseport_detach_sock(sk, reuse);
-			__reuseport_add_closed_sock(sk, reuse);
+			if (__reuseport_detach_sock(sk, reuse))
+				__reuseport_add_closed_sock(sk, reuse);
 
 			spin_unlock_bh(&reuseport_lock);
 			return;
-- 
2.55.0

Re: [PATCH net] net: reuseport: avoid duplicate closed socket insertion

[netdev-bot+sinfo]

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.

Re: [PATCH net] net: reuseport: avoid duplicate closed socket insertion

[Lin Jiapeng]

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.