From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ed1-f54.google.com (mail-ed1-f54.google.com [209.85.208.54]) (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 1ED9738B7D6 for ; Wed, 24 Jun 2026 13:36:08 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.208.54 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782308172; cv=none; b=YI5JxL0MDyczYZC44q58sQCk4vTxrLSYQ4bf1zNd2ghvF1LitU9Z/juj19alDkYCagAWeIhtYdeBBRCw0pEdTy2xFMf8YtcCnL014J3ebzxNuEk3ETB9J2mJEIwLX1hYcLJM3+pQ4w7mm+Z6I6AMD8PxVMQcNc9qu9SCvzScvk8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782308172; c=relaxed/simple; bh=i/PjI4m04aPw0PQLU5HQ2rF0LE8MVaue1ZoAwrK1SYE=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=fSi7exNflUKEubvT+OQBtZxC/+95ZkngVyaY1WxfixKZBE4pxIgUf6KmmAetZ6snyS7Rvp7JAe03NjqR2G5Y1aSJrUr1KdvLHq4A9W/8QrD45JHfVuT+ihNGsGliep05wDHgD3FPfS0Xe9Or+kqATYYjjpdvZwBMWVqVejshBNk= 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=HpUn2zPj; arc=none smtp.client-ip=209.85.208.54 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="HpUn2zPj" Received: by mail-ed1-f54.google.com with SMTP id 4fb4d7f45d1cf-6974a6e54dbso1933105a12.2 for ; Wed, 24 Jun 2026 06:36:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google09082023; t=1782308167; x=1782912967; darn=vger.kernel.org; h=mime-version:message-id:date:user-agent:references:in-reply-to :subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to; bh=RvxFHr+pWEoc4bhYu8JwbhnPbjylaRVmeM2W41MKswU=; b=HpUn2zPjP4mX6UAQRBTOkdF3i/ZQkh+OBP5R9zfZr4UV1ikejir6e27iIYyUjgSoOE dydBVdYbDakXnIAcNbvMc34cqvyItyiDGLgHyWZYHJtDf9DtE2KY0rh1VqcQec7BPaQ7 VO+r1TEbGMNQKxrGX+7HcqyAcfIiuuvNi/7fzx5DKIZqi/sBPKIJDmxbUIX/2+IbgcwX kPFggf+LXSmiiQUrgfNAjgv31sEpcUndyONlCE+p2mhtJIQtfUaqhLC6uJUe5A9f1NRe vw0/X/Yc2ZSTrTtGxeHoSKuvUYx2yYk5yQJOYr1NbY6f/8kXw3/STbSUZ3WFKpYNolsl xCHw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1782308167; x=1782912967; h=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; bh=RvxFHr+pWEoc4bhYu8JwbhnPbjylaRVmeM2W41MKswU=; b=CvMpBtYIR5PPGeI8U8z7tvAIAgz2PMIq9FO07P8pqutT1Vm+RSLWSQSuUwDnVI7jt5 VlYDqxLiOgs57c8rdR8emRXA66NqtL4RTLGC3yHhi97iYU70LTsipgKjeh9oFF8CLTm1 6pHhd/4tFP5q3JHiO3et6PiJXjgJwhlWowrN6L8P6AwmabX7OOfILe9hAOevfdWgZplr rjMAKxWMKRKA43CZCyyDlYWbJ1jFLlOaYZWv3sM+PIZSsNlh/CalvjBwRAS0NHidWDZ3 PasM5oNDjaf9y4rI7fHgW3xqA4OH8xpltYb9+83G+laRNbtmDIKQujlrOa9TmAvkLSDy OLrQ== X-Forwarded-Encrypted: i=1; AHgh+RrMU3mj85WV4wJKG81EUyxq8yDu/b2ELEH38lFC69f4kglAcgbuOhY9tYOvYTbaudn2jDs0yoiZ7qefaQg=@vger.kernel.org X-Gm-Message-State: AOJu0YwPUebFRmhP+6OFcEVLmy1JpqY8dr88ovBqAugBhvixSmcIqLCE EqgUNZiwaR45TVtKD4RmqH/NxjD12ipmXPZiz7PgFLp+1Es6reLKLxz7eevIzahsIzM= X-Gm-Gg: AfdE7clKmzz6QsvsSKgXz4QxGTS83HutWkk0el+jzodm1DgKfo75VdvHxuTMXnkxx47 wQiD+TCSLkmawHcYHULAF0Wtpyny56heDfsTT8M5oQckzK02jO++U8xVDEBRcYX1fwvC4FTGZTS Ki0b/GXUpk2IwdswPhAds6+fjQEu4CkqcIemYMQ0VpevMIJJeqOHx25VcXmTQ/v737iEwu5eYhw yOdeMyzwDYJj4uKPXjNJzIxI1dRRrXW62VepWAzY3ORQH5NVIorfpFHaYZhGKV/kVgfu7TmGasv DtseAyWYQKLTJXoDe5+GXiGvTgKqXf354O2jff7fRX/a4QV9ZbdaMexrduynaXfOiqL2EuRYt5+ j8Z/E4r/i6iDLSpjgSgcMsN/THPnM/dmlQMm8XMMgCSSKMjPaNyRP1SA/vaNOBqjSjipwCujd1Z MkBLTdQbW75oxk834= X-Received: by 2002:a05:6402:1e91:b0:697:de64:ae9a with SMTP id 4fb4d7f45d1cf-697f376fafamr1997570a12.6.1782308167524; Wed, 24 Jun 2026 06:36:07 -0700 (PDT) Received: from cloudflare.com ([104.28.21.182]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-697f4bd36adsm1202161a12.27.2026.06.24.06.36.06 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 24 Jun 2026 06:36:07 -0700 (PDT) From: Jakub Sitnicki To: Michal Luczaj , Willem de Bruijn Cc: John Fastabend , Jiayuan Chen , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Simon Horman , Alexei Starovoitov , Cong Wang , Daniel Borkmann , Andrii Nakryiko , Eduard Zingerman , Kumar Kartikeya Dwivedi , Martin KaFai Lau , Song Liu , Yonghong Song , Jiri Olsa , Emil Tsalapatis , Shuah Khan , netdev@vger.kernel.org, bpf@vger.kernel.org, linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org Subject: Re: [PATCH bpf 1/2] bpf, sockmap: Don't leak UDP socks on lookup-bind-release In-Reply-To: <20260623-sockmap-lookup-udp-leak-v1-1-05804f9308e4@rbox.co> (Michal Luczaj's message of "Tue, 23 Jun 2026 20:03:09 +0200") References: <20260623-sockmap-lookup-udp-leak-v1-0-05804f9308e4@rbox.co> <20260623-sockmap-lookup-udp-leak-v1-1-05804f9308e4@rbox.co> User-Agent: mu4e 1.14.1; emacs 30.2 Date: Wed, 24 Jun 2026 15:36:06 +0200 Message-ID: <87wlvoxdq1.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 Tue, Jun 23, 2026 at 08:03 PM +02, Michal Luczaj wrote: > UDP sockets get SOCK_RCU_FREE set when (auto-)bound. This means > sk_is_refcounted(unbound) = true, while sk_is_refcounted(bound) = false. > > Because sockmap accepts unbound UDP sockets, a BPF program can increment a > socket's refcount via lookup. If the socket is subsequently bound, the > transition from unbound to bound causes bpf_sk_release() to skip the > decrement of the refcount, causing a memory leak. > > unreferenced object 0xffff88810bc2eb40 (size 1984): > comm "test_progs", pid 2451, jiffies 4295320596 > hex dump (first 32 bytes): > 7f 00 00 01 7f 00 00 01 d2 04 1b b7 04 d2 00 00 ................ > 02 00 01 40 00 00 00 00 00 00 00 00 00 00 00 00 ...@............ > backtrace (crc bdee079d): > kmem_cache_alloc_noprof+0x557/0x660 > sk_prot_alloc+0x69/0x240 > sk_alloc+0x30/0x460 > inet_create+0x2ce/0xf80 > __sock_create+0x25b/0x5c0 > __sys_socket+0x119/0x1d0 > __x64_sys_socket+0x72/0xd0 > do_syscall_64+0xa1/0x5f0 > entry_SYSCALL_64_after_hwframe+0x76/0x7e > > Maintain balanced refcounts across sk lookup/release: (re-)set > SOCK_RCU_FREE on proto update to treat the socket (whether bound or > unbound) as not requiring a refcount increment on (a RCU protected) lookup. > > Fixes: 0c48eefae712 ("sock_map: Lift socket state restriction for datagram sockets") > Signed-off-by: Michal Luczaj > --- > Note: this issue is related to commit 67312adc96b5 ("bpf: reject unhashed > sockets in bpf_sk_assign"). > --- > net/ipv4/udp_bpf.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/net/ipv4/udp_bpf.c b/net/ipv4/udp_bpf.c > index ad57c4c9eaab..970327b59582 100644 > --- a/net/ipv4/udp_bpf.c > +++ b/net/ipv4/udp_bpf.c > @@ -173,6 +173,9 @@ int udp_bpf_update_proto(struct sock *sk, struct sk_psock *psock, bool restore) > if (sk->sk_family == AF_INET6) > udp_bpf_check_v6_needs_rebuild(psock->sk_proto); > > + /* Treat all sockets as non-refcounted, regardless of binding state. */ > + sock_set_flag(sk, SOCK_RCU_FREE); > + > sock_replace_proto(sk, &udp_bpf_prots[family]); > return 0; > } There is a side effect that an unhashed (unbound) UDP socket can now be selected in sk_lookup with bpf_sk_assign. Though perhaps that's for the better because TC bpf_sk_assign doesn't reject non-refcounted UDP sockets either, so we would have both socket dispatch sites behave the same way. Also, with this patch, if we insert & remove an unhashed UDP socket into/from a sockmap, we end up with an unhashed non-refcounted UDP socket. Not entirely sure if that is actually a problem or not. Willem, what is your take on having unhashed non-refcoted UDP sockets?