From: sashiko-bot@kernel.org
To: "Michal Luczaj" <mhal@rbox.co>
Cc: bpf@vger.kernel.org
Subject: Re: [PATCH bpf v2 2/2] bpf: Unconditionally take socket references in lookup helpers
Date: Mon, 03 Aug 2026 09:35:44 +0000 [thread overview]
Message-ID: <20260803093544.E44741F00A3A@smtp.kernel.org> (raw)
In-Reply-To: <20260803-sockmap-lookup-tcp-leak-v2-2-306e025bfe66@rbox.co>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] A pre-existing socket reference leak exists when `bpf_sk_assign()` assigns a socket to an skb and `sock_pfree()` acts as the destructor. `bpf_sk_assign()` conditionally increments the reference count if `sk_is_refcounted()` returns true, but `sock_pfree()` independently re-evaluates `sk_is_refcounted()`. If the socket transitions to `SOCK_RCU_FREE` between these two calls (e.g., via `connect(AF_UNSPEC)` followed by `listen()`), `sock_pfree()` returns early without calling `sock_gen_put()`, permanently leaking the reference.
--
--- Patch [2]: [PATCH bpf v2 2/2] bpf: Unconditionally take socket references in lookup helpers ---
commit 7463d9a6a26a249e959688cc8e1b8c2847ee47d0
Author: Michal Luczaj <mhal@rbox.co>
bpf: Unconditionally take socket references in lookup helpers
This commit updates BPF socket lookup helpers to unconditionally acquire
and release socket references. It fixes a leak that occurs if a socket
transitions to SOCK_RCU_FREE between the time the reference is
conditionally taken and released.
Closes: https://lore.kernel.org/bpf/20260701235552.2B0AA1F00A3F@smtp.kernel.org/
> 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.
[Severity: High]
This is a pre-existing issue, but as you noted, a socket reference is
permanently leaked if the socket state changes to unrefcounted between
bpf_sk_assign() and the skb destructor running.
In net/core/filter.c:bpf_sk_assign(), the reference is conditionally acquired
and the destructor is set:
if (sk_is_refcounted(sk) &&
unlikely(!refcount_inc_not_zero(&sk->sk_refcnt)))
return -ENOENT;
skb_orphan(skb);
skb->sk = sk;
skb->destructor = sock_pfree;
Then in net/core/sock.c:sock_pfree(), the reference drop is independently
evaluated:
void sock_pfree(struct sk_buff *skb)
{
struct sock *sk = skb->sk;
if (!sk_is_refcounted(sk))
return;
...
sock_gen_put(sk);
}
If the socket transitions to SOCK_RCU_FREE via a connect(AF_UNSPEC) followed
by a listen() before the skb is freed, sock_pfree() returns early without
calling sock_gen_put().
Could this be addressed by either applying the same unconditional reference
counting approach to bpf_sk_assign(), or by introducing a dedicated
destructor for BPF-assigned sockets that unconditionally drops the reference
without re-evaluating sk_is_refcounted()?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260803-sockmap-lookup-tcp-leak-v2-0-306e025bfe66@rbox.co?part=2
next prev parent reply other threads:[~2026-08-03 9:35 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-03 9:00 [PATCH bpf v2 0/2] bpf: Fix socket leaks around connect(AF_UNSPEC)+listen() Michal Luczaj
2026-08-03 9:00 ` [PATCH bpf v2 1/2] bpf: Extract shared reqsk-to-listener upgrade Michal Luczaj
2026-08-03 9:44 ` bot+bpf-ci
2026-08-03 10:43 ` Michal Luczaj
2026-08-04 10:07 ` Jakub Sitnicki
2026-08-03 9:00 ` [PATCH bpf v2 2/2] bpf: Unconditionally take socket references in lookup helpers Michal Luczaj
2026-08-03 9:35 ` sashiko-bot [this message]
2026-08-03 14:14 ` Michal Luczaj
2026-08-04 1:58 ` Kuniyuki Iwashima
2026-08-04 10:14 ` Jakub Sitnicki
2026-08-05 4:01 ` Kuniyuki Iwashima
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260803093544.E44741F00A3A@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=mhal@rbox.co \
--cc=sashiko-reviews@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).