From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ej2-f43.google.com (mail-ej2-f43.google.com [74.125.228.171]) (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 08F4D2D0620 for ; Tue, 29 Sep 2026 15:31:19 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.228.171 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1790695883; cv=none; b=iaqTXuLNf02+DZ6o/YU9qG/N5KgbgePv2Ob4XZA9k88MFmVW0zKwaErJM0IOvZimg8za3MRNzexef2bOxcOk6rGkNYTts1L4BrvnAeyUPK4uPsD8Tk0lP6OBCvUXEWpIyNQjm7yy4YTLqDiYlHF/aLnWqAF9FxP6p9RS64F56uQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1790695883; c=relaxed/simple; bh=V9lg38Vf7jZapxl1nX3JHinivXWDameN/IxWV3yotv8=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Message-Id:References:To; b=Z0M7ODj68hXN/s4zdhyOzRe/hqojLCo4ezsAo127JjjHycO+4er/42W06TfYhvD0uqNb0Xceyrbj48wddwz75kyzrlYESQHpzxW4KGqA2GyaiC5yFmleZ0sWNJzkvYrngx3Gwb3WYApnsioQKJVKDIrZGxNQBOBsrEL9o8PgScE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=doyensec.com; spf=pass smtp.mailfrom=doyensec.com; dkim=pass (2048-bit key) header.d=doyensec.com header.i=@doyensec.com header.b=i+oa0SA1; arc=none smtp.client-ip=74.125.228.171 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=doyensec.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=doyensec.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=doyensec.com header.i=@doyensec.com header.b="i+oa0SA1" Received: by mail-ej2-f43.google.com with SMTP id a640c23a62f3a-c2af43c5b0cso563381666b.1 for ; Tue, 29 Sep 2026 08:31:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=doyensec.com; s=google; t=1790695878; x=1791300678; darn=vger.kernel.org; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:content-type:from:to:cc :subject:date:message-id:reply-to:content-type; bh=KUokiXULiB5QsBWdM9hQZjEq8BVs/Diba1IyZLK0fCQ=; b=i+oa0SA1I0ql0x913EiKlVthwnGVMwsg9W40HEl7RNvJoE6krGwXeVBRjO0apYZ3BK Iks52N9H6DbTTyLWmfGvNy2C435s3p0Q+FuBH/mQgHK3bwTJARWTyNPCMD68v541deBD MoEjUXaw97/m0DQj7bMH8Ci7OdnzUCriUlcRfIYKk2Yxv1F6ctF+BaTuz2HZQedW7GA8 SP/ovagLqDK+oj6iwtBadN4/UrKJ7Ikqao3V1bOCayYobPNZWspV257mnCgr6uD/M+rY IgqCdIa4xNtToaOc8RAiqhwYJ5VB4O7Rcjz9+DVzKhTiIhNkIQihHSoJgKxtG43l1Noh DpOA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790695878; x=1791300678; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:content-type:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=KUokiXULiB5QsBWdM9hQZjEq8BVs/Diba1IyZLK0fCQ=; b=HKJjnnv4bSaHohL1lYdOiwNWrgWuKMdWt36HEScMaSEpXavmUbYG1YJGSryrgAeRd8 6vxR3pMSExYKG7L2xOKBG0FPajKKLq9TpkI+a1hjgNVbomayenRZwqYplAvB6THbvxiN imxmwVdbX0SigSXiGNIc6k8bmZnyjqVG3eOG+MZDl/tdIFQYzc5TUQyRcRqykKA4ey9T z8T/7SjsIh1b9/lKiKAYdHZfojxrHw8QojlGd0M87OZlJghGbtW5IpnGfTkY0iwsb/4o PbyJCY03kBX8nxepI95C4Khb5QFzMKVre/u4iAYxFmiHTWsrV66nSliCRPlEOII+7Lr6 +TBQ== X-Forwarded-Encrypted: i=1; AKwUvBxCkHN08ULJPZsgv/uUx0EmWlCR2ayZVvjohx0c4wO/lxeLAz39xFRtu+set6A83D3xED/BNuQ7GC0H+Sw=@vger.kernel.org X-Gm-Message-State: AFuF++mZa6tvAXTS9o0DMC1gVcNRep+fgMVfnzXxFOFnUSLXwCbzf9fu 0sXTYsGHs3pIy+YQLh9PvjtdS2EeSlgQyntGfJvIrACGBe6jzi3iUVqXXbh4i9KpjFE= X-Gm-Gg: AYBFou3hE8NnG8Ekr+RrWC7GGvwNoK9VxW7yfDJNAgZ3EaEhkUr0WkPr6cJCCwIl3EB eK7u3+Jf0l9irTafWtmML1U4/WLNK2yE3TE4SJ8WhN0KbJ2c6YfG967yfgXvoLBY+X8AY/MWOzS 1dUii7TZWYyT1UHOx58ZDUvoAGlE/Ed1x7jdYA8I/ZY4/VpHf6SOvFLqeKIseAV00l4jWjgD6kI YuurZ6q6CBKCdM1OVldFtvSNS7qD9z1dcbdDGy87eRL1Ms4UqQgNNZ9FxmHFqojtyAYfoKolaPh kotbE3/xcZhcH9cqC/RoIOY7GKa0+ytjG+aBDJ/BUSyoqYNQyUuKab7G1fj+PrX+xM+vx6Rmihi 0l4apX1J2QtN73c7tVp8g9l5hdccybLlbhivGCkAG3xyvI3awR9+CLe54gnjJfq/xwqXBPd/MOO ug4MG6QFYEOgans+RUiPmrtM08Oy/KaQ5YfblWhZ1x2rBFTEFiMjT4/FHyY3DT6aPhMS1icT7Yl IejEjDvq8gM4+S4Li7RIzLbIIWGrOTCPvX7hRuD4D2d4EWO0NZiCe5ABXEiYMynW4XiJ/9P X-Received: by 2002:a17:907:c8c8:b0:c25:62db:772b with SMTP id a640c23a62f3a-c2ac23858f0mr1428859766b.7.1790695878179; Tue, 29 Sep 2026 08:31:18 -0700 (PDT) Received: from smtpclient.apple (80.49.145.194.ipv4.supernova.orange.pl. [80.49.145.194]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-c2e11b9b22fsm1416666b.6.2026.09.29.08.31.15 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 29 Sep 2026 08:31:16 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3864.700.51.1.1\)) Subject: Re: [PATCH net] soreuseport: Fix use-after-free when a socket is added to socks[] twice From: Norbert Szetei In-Reply-To: <20260928174546.4022833-1-kuniyu@google.com> Date: Tue, 29 Sep 2026 17:30:57 +0200 Cc: daniel@iogearbox.net, davem@davemloft.net, edumazet@kernel.org, horms@kernel.org, kuba@kernel.org, linux-kernel@vger.kernel.org, martin.lau@linux.dev, netdev@vger.kernel.org, pabeni@redhat.com, willemb@google.com Content-Transfer-Encoding: quoted-printable Message-Id: References: <6E4F8645-9453-45F1-B068-52E1B14E8B0C@doyensec.com> <20260928174546.4022833-1-kuniyu@google.com> To: Kuniyuki Iwashima X-Mailer: Apple Mail (2.3864.700.51.1.1) On Sep 28, 2026, at 19:45, Kuniyuki Iwashima wrote: > This has long been a known problem, and I think it's time > to fix it instead of working around it: >=20 > diff --git a/net/core/sock.c b/net/core/sock.c > index 2948dffcc3e1..a33cdf99368d 100644 > --- a/net/core/sock.c > +++ b/net/core/sock.c > @@ -1324,6 +1324,8 @@ int sk_setsockopt(struct sock *sk, int level, = int optname, > case SO_REUSEPORT: > if (valbool && !sk_is_inet(sk)) > ret =3D -EOPNOTSUPP; > + else if (!valbool && rcu_access_pointer(sk->sk_reuseport_cb)) > + ret =3D -EBUSY; > else > sk->sk_reuseport =3D valbool; > break; Thanks for the suggestion. I tested it with my sock_reuseport.c change = dropped and I was not able to reproduce the issue, and migration and resurrect = still work. One question before I send it as v2 with Suggested-by: you, unless you would rather post it yourself. Should the check be restricted to TCP? else if (!valbool && sk->sk_protocol =3D=3D IPPROTO_TCP && rcu_access_pointer(sk->sk_reuseport_cb)) ret =3D -EBUSY; The closed section only exists for TCP, so TCP is the only protocol = where clearing the flag leads to the double add. With the check as it is, a = bound UDP socket also starts getting EBUSY from setsockopt(SO_REUSEPORT, 0). N. >> Clearing it between shutdown() and listen() makes that listen() skip >> reuseport_add_sock(), and with it reuseport_resurrect(), so the = socket is >> hashed as a listener while it is still in the closed section. On the = next >> shutdown() __reuseport_detach_sock() does not find it in the = listening >> section, returns false, and __reuseport_add_closed_sock() adds a = second >> copy of it to socks[]. >>=20 >> sk_destruct() calls reuseport_detach_sock(), which removes one of the = two >> entries. reuseport_grow() then dereferences the other one, because = its >> loop runs over every slot up to reuse->max_socks: >>=20 >> BUG: KASAN: slab-use-after-free in reuseport_grow = (net/core/sock_reuseport.c:291) >> Write of size 8 at addr ffff888132359988 by task poc/621 >>=20 >> reuseport_grow (net/core/sock_reuseport.c:291) >> reuseport_add_sock (net/core/sock_reuseport.c:350) >> inet_hash (net/ipv4/inet_hashtables.c:810) >> inet_csk_listen_start (net/ipv4/inet_connection_sock.c:1359) >> __inet_listen_sk (net/ipv4/af_inet.c:225) >> inet_listen (net/ipv4/af_inet.c:247) >> __sys_listen (net/socket.c:2014) >>=20 >> Allocated by task 621: >> sk_prot_alloc (net/core/sock.c:2246) >> sk_alloc (net/core/sock.c:2308) >> inet_create (net/ipv4/af_inet.c:333) >>=20 >> Freed by task 0: >> slab_free_after_rcu_debug (mm/slub.c:6570) >> rcu_core (kernel/rcu/tree.c:2919) >>=20 >> The buggy address is located 904 bytes inside of >> freed 2624-byte region [ffff888132359600, ffff88813235a040) >>=20 >> Only move the socket to the closed section when = __reuseport_detach_sock() >> reports that it was removed from the listening section. >>=20 >> Fixes: 333bb73f620e ("tcp: Keep TCP_CLOSE sockets in the reuseport = group.") >> Assisted-by: LLM >> Signed-off-by: Norbert Szetei >> --- >> net/core/sock_reuseport.c | 4 ++-- >> 1 file changed, 2 insertions(+), 2 deletions(-) >>=20 >> diff --git a/net/core/sock_reuseport.c b/net/core/sock_reuseport.c >> index 29948cb44b7d..031b641be317 100644 >> --- a/net/core/sock_reuseport.c >> +++ b/net/core/sock_reuseport.c >> @@ -479,8 +479,8 @@ void reuseport_stop_listen_sock(struct sock *sk) >> */ >> bpf_sk_reuseport_detach(sk); >>=20 >> - __reuseport_detach_sock(sk, reuse); >> - __reuseport_add_closed_sock(sk, reuse); >> + if (__reuseport_detach_sock(sk, reuse)) >> + __reuseport_add_closed_sock(sk, reuse); >>=20 >> spin_unlock_bh(&reuseport_lock); >> return; >> --=20 >> 2.55.0 >>=20