From: Sabrina Dubroca <sd@queasysnail.net>
To: Eric Dumazet <edumazet@google.com>
Cc: Paolo Abeni <pabeni@redhat.com>,
"David S . Miller" <davem@davemloft.net>,
Jakub Kicinski <kuba@kernel.org>, Simon Horman <horms@kernel.org>,
Willem de Bruijn <willemb@google.com>,
netdev@vger.kernel.org, eric.dumazet@gmail.com,
Michal Kubecek <mkubecek@suse.cz>
Subject: Re: [PATCH net] udp: drop secpath before storing an skb in a receive queue
Date: Tue, 14 Oct 2025 10:28:25 +0200 [thread overview]
Message-ID: <aO4JqeYJftHa-I8O@krikkit> (raw)
In-Reply-To: <CANn89iK6w0CNzMqRJiA7QN2Ap3AFWpqWYhbB55RcHPeLq6xzyg@mail.gmail.com>
2025-10-14, 01:06:04 -0700, Eric Dumazet wrote:
> On Tue, Oct 14, 2025 at 1:01 AM Eric Dumazet <edumazet@google.com> wrote:
> >
> > On Tue, Oct 14, 2025 at 12:43 AM Eric Dumazet <edumazet@google.com> wrote:
> > >
> > > On Tue, Oct 14, 2025 at 12:32 AM Paolo Abeni <pabeni@redhat.com> wrote:
> > > >
> > > >
> > > >
> > > > On 10/14/25 8:37 AM, Sabrina Dubroca wrote:
> > > > > 2025-10-14, 06:04:54 +0000, Eric Dumazet wrote:
> > > > >> Michal reported and bisected an issue after recent adoption
> > > > >> of skb_attempt_defer_free() in UDP.
> > > > >>
> > > > >> We had the same issue for TCP, that Sabrina fixed in commit 9b6412e6979f
> > > > >> ("tcp: drop secpath at the same time as we currently drop dst")
> > > > >
> > > > > I'm not convinced this is the same bug. The TCP one was a "leaked"
> > > > > reference (delayed put). This looks more like a double put/missing
> > > > > hold to me (we get to the destroy path without having done the proper
> > > > > delete, which would set XFRM_STATE_DEAD).
> > > > >
> > > > > And this shouldn't be an issue after b441cf3f8c4b ("xfrm: delete
> > > > > x->tunnel as we delete x").
> > > >
> > > > I think Sabrina is right. If the skb carries a secpath,
> > > > UDP_SKB_IS_STATELESS is not set, and skb_release_head_state() will be
> > > > called by skb_consume_udp().
> > > >
> > > > skb_ext_put() does not clear skb->extensions nor ext->refcnt, if
> > > > skb_attempt_defer_free() enters the slow path (kfree_skb_napi_cache()),
> > > > the skb will go through again skb_release_head_state(), with a double free.
> > > >
> > > > I think something alike the following (completely untested) should work:
> > > > ---
> > > > diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
> > > > index 95241093b7f0..4a308fd6aa6c 100644
> > > > --- a/net/ipv4/udp.c
> > > > +++ b/net/ipv4/udp.c
> > > > @@ -1851,8 +1851,10 @@ void skb_consume_udp(struct sock *sk, struct
> > > > sk_buff *skb, int len)
> > > > sk_peek_offset_bwd(sk, len);
> > > >
> > > > if (!skb_shared(skb)) {
> > > > - if (unlikely(udp_skb_has_head_state(skb)))
> > > > + if (unlikely(udp_skb_has_head_state(skb))) {
> > > > skb_release_head_state(skb);
> > > > + skb->active_extensions = 0;
> >
> > We probably also want to clear CONNTRACK state as well.
>
> Perhaps not use skb_release_head_state() ?
>
> We know there is no dst, and no destructor.
Then, do we need to do anything before calling skb_attempt_defer_free()?
skb_attempt_defer_free() only wants no dst and no destructor, and the
secpath issue that we dealt with in TCP is not a problem anymore.
Can we just drop the udp_skb_has_head_state() special handling and
simply call skb_attempt_defer_free()?
> diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
> index 95241093b7f0..98628486c4c5 100644
> --- a/net/ipv4/udp.c
> +++ b/net/ipv4/udp.c
> @@ -1851,8 +1851,10 @@ void skb_consume_udp(struct sock *sk, struct
> sk_buff *skb, int len)
> sk_peek_offset_bwd(sk, len);
>
> if (!skb_shared(skb)) {
> - if (unlikely(udp_skb_has_head_state(skb)))
> - skb_release_head_state(skb);
> + if (unlikely(udp_skb_has_head_state(skb))) {
> + nf_reset_ct(skb);
> + skb_ext_reset(skb);
> + }
> skb_attempt_defer_free(skb);
> return;
> }
--
Sabrina
next prev parent reply other threads:[~2025-10-14 8:28 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-14 6:04 [PATCH net] udp: drop secpath before storing an skb in a receive queue Eric Dumazet
2025-10-14 6:37 ` Sabrina Dubroca
2025-10-14 6:54 ` Eric Dumazet
2025-10-14 7:32 ` Paolo Abeni
2025-10-14 7:43 ` Eric Dumazet
2025-10-14 8:01 ` Eric Dumazet
2025-10-14 8:06 ` Eric Dumazet
2025-10-14 8:27 ` Eric Dumazet
2025-10-14 8:55 ` Paolo Abeni
2025-10-14 11:20 ` Michal Kubecek
2025-10-14 11:34 ` Eric Dumazet
2025-10-14 13:18 ` Michal Kubecek
2025-10-14 13:40 ` Florian Westphal
2025-10-14 13:58 ` Eric Dumazet
2025-10-14 8:28 ` Sabrina Dubroca [this message]
2025-10-14 8:33 ` Eric Dumazet
2025-10-14 7:45 ` Sabrina Dubroca
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=aO4JqeYJftHa-I8O@krikkit \
--to=sd@queasysnail.net \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=eric.dumazet@gmail.com \
--cc=horms@kernel.org \
--cc=kuba@kernel.org \
--cc=mkubecek@suse.cz \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=willemb@google.com \
/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.