From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ej1-f41.google.com (mail-ej1-f41.google.com [209.85.218.41]) (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 085963D25C2 for ; Wed, 5 Aug 2026 18:27:40 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.218.41 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785954465; cv=none; b=ShgayBrjChzDPlMwV7+PFDk38IBls5bVsaPMT4UXadW+S0ftfR0yis2Slvw0y2y0uBKxuSuUudU1SaGo11N9RBI9P7nFqCxBRiMciDnis4AxmK3JS1xgCepxbqlku3eXzvEbSyn91bzWcMwG2NMINY3PqKx6NpcmI168fG0OOE8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785954465; c=relaxed/simple; bh=D80ENpUfW4QvugcwsDaQo9rQ3VT0nERraW1zaHCo3FY=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=Fg02LvIKaWVy394kBm0DzyN4FZ/bc3uWxH+JSet2KWlh16digkxG+nM6VPgpKKz4VaZT8VZrvEnPy5lDDTMFBcVY066pDf14XFsdjrLjdi5jVpsM7QYCDIFZBnuqwatAUUNGkImEXIP2nAUlCCgVMlc5xH6tqR8JL7IgV7MieU8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=cloudflare.com; spf=pass smtp.mailfrom=cloudflare.com; dkim=pass (2048-bit key) header.d=cloudflare.com header.i=@cloudflare.com header.b=XGOr2sCj; arc=none smtp.client-ip=209.85.218.41 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=cloudflare.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=cloudflare.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=cloudflare.com header.i=@cloudflare.com header.b="XGOr2sCj" Received: by mail-ej1-f41.google.com with SMTP id a640c23a62f3a-c1670dad7a8so200464966b.3 for ; Wed, 05 Aug 2026 11:27:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google09082023; t=1785954459; x=1786559259; darn=vger.kernel.org; h=content-type:mime-version:message-id:date:user-agent:references :in-reply-to:subject:cc:to:from:from:to:cc:subject:date:message-id :reply-to:content-type; bh=RQvUfHBgP2cWCg3xbn5qxeCgrthmPBmHR+/z9WzFaXg=; b=XGOr2sCjwR1DuM9tHgx5gyZQabR98pBqaPwKy7xuE7UFnCL2N9UUMCktzkLnPndFei qkXz5BlMaujSEvZMiXoUbkR5Vn5wNn02S7Je+3tYv30MJKEodBfkeqzP7K/KboO3vyXJ PSzPAJy8GT7uf+m8z+ZomG3vP4MwbYPeJ+IsWmUKnOn3R0KPAtAEl0s7kMQNvP4XqJbB uDkHiB77bF7dh+tpEi40BS7rffe/cRBwHa1G+nLUHAI4n2KQHM9yuMlLS+iPPC/5DmH1 P6ejA1iMS9MFjUkqhPApFvNXGrdTyJAWoO4BJfYqt2lGrcQyQURg+z1bmiEktSi6AxIJ sfug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1785954459; x=1786559259; h=content-type:mime-version:message-id:date:user-agent:references :in-reply-to:subject:cc:to:from:x-gm-gg:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to:content-type; bh=RQvUfHBgP2cWCg3xbn5qxeCgrthmPBmHR+/z9WzFaXg=; b=eX7NxFT38fJUynHTjefG4bVzuTSVIK41/efMr13gzLhWO5otylqymNOJdCk3EDUVOx EGEARAO6TjKPqR2tt5RY1BhYGA7MI4Qi9jhZLVkhONYQzJoi4JZlTajWx4YNL5QS4k57 f0+IDio/hFVNEZIt+Y0AXpx+ctDbT8cN0ZtIUJk5DghuF1+w28gOW783OiFtYdh+LVcK SpDMS2XOvAq9/18h+zymmzrortjyJayGPhN62a0Ze2kgi1Z26L+vSrTFSQVlnfxfyPbL gca92RjS7HcNzsyxVJD4VdMX2DYH70VOvLNjw1fKzTn3chNN6GPIvMbwNYL0WUn5j2Yt STsw== X-Forwarded-Encrypted: i=1; AHgh+RrE6ICGo2s+2aXuhTTK0oi2OwL5S11uUavBX/KCMniJEx1rYcQeejXUq1x/c4xWed1RWytGVNmfwktwxkU=@vger.kernel.org X-Gm-Message-State: AOJu0YzMq9SbqRBtyD9bQC6CEmeozvWXf6BKSQ8CmUj2zdmJ+uT/03+s rtgLPBGoIGrpSvWnjNQVGIZ54812IsPHvH9tWZ3xwO1GBkMpxoGPh2RoUoYDuXNPH1c= X-Gm-Gg: AR+sD107Mu5zCOYJdfFvFsnOIDFZHgaSIXDcaBDkGcsmZMVCXx8PW9koJetmk9/HbTE f1OOXplQ1JRHEl9p+4IUMDHYIJsUyeoaTh/fMhfFMDIk/Eh8xfpnw568AhtDj3uD8TeQZ7+VNcl MjeTD6NLpV0xEfep0RvbR9/V/P5+pbid9o6jkfcOgRAU2dCTta5myV/D4genrWa1Nhz69nY/yI4 2JvER032BD0KrKWvGsfWEtWjYNGABbqnpRgdyCdnHqcpBQmPT2MR7hwEVnuFLxvSQonIj4an5ky 4uStgDtcgTxdl/RTV2W4Q28Jtz8PaUzXH/+pcRHGop70MlyoYiyGmHqknF0shRIEZQHqt/1WWI2 fhHhNCCp02SZamGpPQuB/VI3RXARffK84eB92qrYXPdmHgSwLu7TrAwFELnKPv7HrPfPYAnhqmM Bg06iT5fYDQX4dpwgXme1VHo/4SCqcYEVXG92P2owifFYSRDwzm52OAWTYSl4EkFji X-Received: by 2002:a17:907:9481:b0:c1f:c061:569a with SMTP id a640c23a62f3a-c2039ae6a0amr437892166b.7.1785954458887; Wed, 05 Aug 2026 11:27:38 -0700 (PDT) Received: from cloudflare.com ([104.28.21.182]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-c2036426ca8sm149119266b.50.2026.08.05.11.27.37 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 05 Aug 2026 11:27:37 -0700 (PDT) From: Jakub Sitnicki To: Michal Luczaj Cc: Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , Eduard Zingerman , Kumar Kartikeya Dwivedi , Martin KaFai Lau , Song Liu , Yonghong Song , Jiri Olsa , Emil Tsalapatis , John Fastabend , Stanislav Fomichev , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Simon Horman , Kuniyuki Iwashima , Willem de Bruijn , Jiayuan Chen , Joe Stringer , bpf@vger.kernel.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, Sashiko Subject: Re: [PATCH bpf v2 2/2] bpf: Unconditionally take socket references in lookup helpers In-Reply-To: (Michal Luczaj's message of "Wed, 5 Aug 2026 17:00:14 +0200") References: <20260803-sockmap-lookup-tcp-leak-v2-0-306e025bfe66@rbox.co> <20260803-sockmap-lookup-tcp-leak-v2-2-306e025bfe66@rbox.co> <875x1qyyyx.fsf@cloudflare.com> User-Agent: mu4e 1.14.1; emacs 30.2 Date: Wed, 05 Aug 2026 20:27:37 +0200 Message-ID: <87o6fg8lt2.fsf@cloudflare.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain On Wed, Aug 05, 2026 at 05:00 PM +02, Michal Luczaj wrote: > On 8/4/26 12:14, Jakub Sitnicki wrote: >> On Mon, Aug 03, 2026 at 11:00 AM +02, Michal Luczaj wrote: >>> Lookup helpers gate whether to acquire a socket reference on >>> sk_is_refcounted(), a check re-evaluated at release. An established socket >>> refcounted at acquire time can gain SOCK_RCU_FREE via >>> connect(AF_UNSPEC)+listen() before release runs; the release-side re-check >>> then reads sk_is_refcounted() == false and skips the put. The reference >>> leaks. >>> >>> Make acquire and release unconditional and symmetric: always take a >>> reference, always put it. Adapt sk_select_reuseport(). >>> >>> Fixes: 6acc9b432e67 ("bpf: Add helper to retrieve socket in BPF") >>> Fixes: 64d85290d79c ("bpf: Allow bpf_map_lookup_elem for SOCKMAP and SOCKHASH") >>> Reported-by: Sashiko >>> Closes: https://lore.kernel.org/bpf/20260701235552.2B0AA1F00A3F@smtp.kernel.org/ >>> Signed-off-by: Michal Luczaj >>> Reviewed-by: Emil Tsalapatis >>> --- >>> TC bpf_sk_assign() has the same issue; it takes a reference only when >>> sk_is_refcounted() is true at assign time, but sock_pfree() (the skb >>> destructor it installs) re-checks sk_is_refcounted() independently at >>> release time. The same connect(AF_UNSPEC)+listen() transition leaks the >>> socket here too. I'd welcome suggestions on the right way to handle this. >> >> Can we make this scenario unsupported? >> >> listen() could return EBUSY if called on a socket that is refcounted. >> >> WDYT? > > I'm not sure I understand. Isn't a freshly created socket already > refcounted? Yeah, it's just me not thinking this through. We don't have any state today to check if a socket was an established socket before.