From: sashiko-bot@kernel.org
To: "Jordan Rife" <jrife@google.com>
Cc: bpf@vger.kernel.org
Subject: Re: [PATCH net-next v3 2/4] udp: Remove disconnected sockets from the 4-tuple hash
Date: Sat, 25 Apr 2026 02:45:17 +0000 [thread overview]
Message-ID: <20260425024518.9DB59C19425@smtp.kernel.org> (raw)
In-Reply-To: <20260330215707.2374657-3-jrife@google.com>
Sashiko AI review found 2 potential issue(s):
- [High] Calling `udp_unhash4()` from process context with softirqs enabled creates a deadlock vulnerability and lockdep warnings.
- [High] Concurrent executions of `udp_unhash4()` lead to double-decrements of hash bucket counters due to a TOCTOU race.
--
commit e6257404c34b723d1c990d6c54298b3c3edfb986
Author: Jordan Rife <jrife@google.com>
udp: Remove disconnected sockets from the 4-tuple hash
This commit updates udp_disconnect() and udp_abort() to always remove a
disconnected socket from the 4-tuple hash. This is done by calling the newly
introduced udp_disconnect_unhash4() function on disconnect or abort.
> diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
> index 91918ff60728f..e3f7689513d9b 100644
> --- a/net/ipv4/udp.c
> +++ b/net/ipv4/udp.c
> @@ -2235,10 +2235,20 @@ int __udp_disconnect(struct sock *sk, int flags)
> }
> EXPORT_SYMBOL(__udp_disconnect);
>
> +static int udp_disconnect_unhash4(struct sock *sk, int flags)
> +{
> + struct udp_table *udptable = udp_get_table_prot(sk);
> +
> + udp_unhash4(udptable, sk);
Is it safe to call udp_unhash4() here with softirqs enabled?
Looking at udp_unhash4(), it acquires hslot4->lock and hslot2->lock using
spin_lock(). Because lock_sock() in udp_disconnect() doesn't disable bottom
halves, an interrupt could occur while hslot4->lock is held.
If a softirq executes a BPF program that calls bpf_sock_destroy() on a
socket in the same bucket, it triggers udp_abort(). As udp_abort() skips
lock_sock(sk) when in BPF context, it will call udp_unhash4() and attempt
to acquire hslot4->lock again, resulting in a deadlock.
Also, could this lead to double-decrements of hash bucket counters?
Inside udp_unhash4(), the if (udp_hashed4(sk)) check is evaluated outside
of any spinlocks. If another path unhashes the socket concurrently (such as
udp_abort() from a BPF context bypassing lock_sock(sk)), both threads can
evaluate udp_hashed4(sk) as true.
Both threads will then serialize on spin_lock(&hslot4->lock). While
hlist_nulls_del_init_rcu() handles already-unhashed nodes, both threads
will unconditionally execute hslot4->count-- and udp_hash4_dec(hslot2),
leading to corrupted hash table counts.
> + __udp_disconnect(sk, flags);
> +
> + return 0;
> +}
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260330215707.2374657-1-jrife@google.com?part=2
next prev parent reply other threads:[~2026-04-25 2:45 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-30 21:57 [PATCH net-next v3 0/4] udp: Preserve UDP socket addresses on abort Jordan Rife
2026-03-30 21:57 ` [PATCH net-next v3 1/4] udp: Only compare daddr/dport when sk_state == TCP_ESTABLISHED Jordan Rife
2026-03-31 1:21 ` Kuniyuki Iwashima
2026-04-01 20:50 ` Jordan Rife
2026-03-30 21:57 ` [PATCH net-next v3 2/4] udp: Remove disconnected sockets from the 4-tuple hash Jordan Rife
2026-03-31 16:51 ` kernel test robot
2026-03-31 17:33 ` kernel test robot
2026-03-31 17:42 ` kernel test robot
2026-03-31 17:55 ` kernel test robot
2026-03-31 18:49 ` kernel test robot
2026-04-25 2:45 ` sashiko-bot [this message]
2026-03-30 21:57 ` [PATCH net-next v3 3/4] udp: Preserve destination address info after abort Jordan Rife
2026-03-30 21:57 ` [PATCH net-next v3 4/4] selftests/bpf: Ensure dst addr/port are preserved after socket abort Jordan Rife
2026-04-25 4:31 ` sashiko-bot
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=20260425024518.9DB59C19425@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=jrife@google.com \
--cc=sashiko@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.