From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ed1-f52.google.com (mail-ed1-f52.google.com [209.85.208.52]) (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 208893B635E for ; Wed, 24 Jun 2026 13:36:08 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.208.52 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782308172; cv=none; b=mCeOUsFniQCsYEL5hvyRwo1ukcruVViIqlSGv9nxMeppUj18AeTPASOXqI0AVV3KnjQhimbh6Zc42sjHvpNhD7YTeosmxLsFU1AJPnGRjF/VP1T8vJ0RWUds4oYqeq2F5n+fyM/V+23LwceJeWmICjVViZ8ZbLwdE38bORM65EE= 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.52 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-f52.google.com with SMTP id 4fb4d7f45d1cf-6974a6e54dbso1933102a12.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=hrqfmKpB//XtZBGudTnK5EKDnwAB+9USsgeSTv6kH2x/IQdgVbpQjjRDNb08M4OuSs 8afbZBAUMPX6AW1KZk2bEUXXtWKz6RQv5UzbYwtrt8JY/8WIrVQGSvLeDPaLve74zxZw HTBEe9wmFWmmRL8R9O9XoQPd/4YvOGBDY2JFiiaoQPoHKWDYpDRT/eXVVCZTZzYDua0/ VZKUr37JkTaGKHCjzr7GC6rSGvbv4c6GPHLUM7PZTTjTV8KhY23OP8EH3vHsXT2oxuV5 ku88Knh5bgTVkIPeSU3mXzm6fNwWvEF96VYK5zU0w7LDH6X1XbC1wMUp+DnnhfuYZ9b2 waxQ== X-Forwarded-Encrypted: i=1; AHgh+Rob3MHfnwrv7yZdUz9R71899emN+AjkAstw9/T5RabpTfhZEyEsTX5ai0RTPUh2yE1ANvW3qWI=@vger.kernel.org X-Gm-Message-State: AOJu0YxQLP3KQPcFElAlEFZPd/ELxyn5Hp/M6nxf/9qx1EUsYpdj1uZ3 jgmTu+5Tjp6app1RKR0YtSMs8svM7SGcD0dJPKSbiQPtuCsfgpKQGu1CgO6vnl2wjTc= X-Gm-Gg: AfdE7cnRNkXOGymXa4jaN9mfm4PGB6n63euZ4HS0HqcbdFZ6QyYziqvr5CHP10uIcXd LiftK7oVzYUgnEWUBe4WgCee0XyG+Tz078DcVTglgSy+zh17WONaD85DY0bWVy8UMcSuKhNpHHy AnsohY0KnVfcsPPgc7oD37v8rOLN/M42R+katJbVz8AVXp9bE+gSa0zR3FZltnZCDHfxHC3148S 4jZYJZmPxq4uSPKBIz2uomFQO577LH0w/XPhirVOaUtbPL8tJjexdjaS+SP+vJLvrAczLef18Jk v3buiUSbbXVCLjqn7+y/LO2NokY66COtxL7iMfghTzHOLmwLyhOn60T5ayL6xlXelqAZXnfBYDn a4gTGJcm6muar4YFkwjYupMiFEtqYA9Ak56rRNJ1r1V3QeESrIzINz82P9B+KyNOA5n03/HLMyr J94qul4clVI4NgWDI= 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: netdev@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?