From: Simon Horman <horms@kernel.org>
To: Antony Antony <antony@phenome.org>
Cc: Antony Antony <antony.antony@secunet.com>,
Steffen Klassert <steffen.klassert@secunet.com>,
Herbert Xu <herbert@gondor.apana.org.au>,
netdev@vger.kernel.org, "David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
devel@linux-ipsec.org
Subject: Re: [devel-ipsec] Re: [PATCH ipsec-next 4/6] xfrm: add XFRM_MSG_MIGRATE_STATE for single SA migration
Date: Fri, 16 Jan 2026 11:26:22 +0000 [thread overview]
Message-ID: <aWogXn5hUay3iTd_@horms.kernel.org> (raw)
In-Reply-To: <aWoatI4v84lJAC48@Antony2201.local>
On Fri, Jan 16, 2026 at 12:02:12PM +0100, Antony Antony wrote:
> On Thu, Jan 15, 2026 at 01:44:50PM +0000, Simon Horman via Devel wrote:
> > On Wed, Jan 14, 2026 at 05:09:20PM +0100, Antony Antony wrote:
> >
> > Hi Antony,
> >
> > > Hi Simon,
> > >
> > > On Tue, Jan 13, 2026 at 02:57:16PM +0000, Simon Horman via Devel wrote:
> > > > On Fri, Jan 09, 2026 at 02:38:05PM +0100, Antony Antony wrote:
> >
> > ...
> >
> > > > > +static int xfrm_send_migrate_state(const struct xfrm_user_migrate_state *um,
> > > > > + const struct xfrm_encap_tmpl *encap,
> > > > > + const struct xfrm_user_offload *xuo)
> > > > > +{
> > > > > + int err;
> > > > > + struct sk_buff *skb;
> > > > > + struct net *net = &init_net;
> > > > > +
> > > > > + skb = nlmsg_new(xfrm_migrate_state_msgsize(!!encap, !!xuo), GFP_ATOMIC);
> > > > > + if (!skb)
> > > > > + return -ENOMEM;
> > > > > +
> > > > > + err = build_migrate_state(skb, um, encap, xuo);
> > > > > + if (err < 0) {
> > > > > + WARN_ON(1);
>
> kfree_skb(skb); replace the above line; explained bellow
>
> > > > > + return err;
> > > >
> > > > skb seems to be leaked here.
> > > >
> > > > Also flagged by Review Prompts.
> > >
> > > I don't see a skb leak. It also looks similar to the functions above.
> >
> > xfrm_get_ae() is the previous caller of nlmsg_new() in this file.
> > It calls BUG_ON() on error, so leaking is not an issue there.
> >
> > The caller before that is xfrm_get_default() which calls kfree_skb() in
> > it's error path. Maybe I'm missing something obvious, but I was thinking
> > that approach is appropriate here too.
>
> You’re right. There is a leak in the error path.
>
> The new helper I added is similar to build_migrate(), but that code uses
> BUG_ON() on the error path. That feels too extreme here (even though there
> are other instances of it in the same file).
FWIIW, the use of BUG_ON in xfrm_get_ae() did give me pause for thought.
>
> I’ll follow the pattern in xfrm_get_default(): handle the error by freeing
> the skb (kfree_skb()) and returning an error. And no WARN_ON().
>
> I’ll send v3 shortly.
Thanks!
next prev parent reply other threads:[~2026-01-16 11:26 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-09 13:29 [PATCH ipsec-next 0/6] xfrm: XFRM_MSG_MIGRATE_STATE new netlink message Antony Antony
2026-01-09 13:37 ` [PATCH ipsec-next 1/6] xfrm: remove redundent assignment Antony Antony
2026-01-13 14:59 ` Simon Horman
2026-01-09 13:37 ` [PATCH ipsec-next 2/6] xfrm: allow migration from UDP encapsulated to non-encapsulated ESP Antony Antony
2026-01-09 13:37 ` [PATCH ipsec-next 3/6] xfrm: rename reqid in xfrm_migrate Antony Antony
2026-01-09 13:38 ` [PATCH ipsec-next 4/6] xfrm: add XFRM_MSG_MIGRATE_STATE for single SA migration Antony Antony
2026-01-13 14:57 ` Simon Horman
2026-01-14 16:09 ` [devel-ipsec] " Antony Antony
2026-01-15 13:44 ` Simon Horman
2026-01-16 11:02 ` Antony Antony
2026-01-16 11:26 ` Simon Horman [this message]
2026-01-09 13:38 ` [PATCH ipsec-next 5/6] xfrm: reqid is invarient in old migration Antony Antony
2026-01-09 13:38 ` [PATCH ipsec-next 6/6] xfrm: check that SA is in VALID state before use Antony Antony
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=aWogXn5hUay3iTd_@horms.kernel.org \
--to=horms@kernel.org \
--cc=antony.antony@secunet.com \
--cc=antony@phenome.org \
--cc=davem@davemloft.net \
--cc=devel@linux-ipsec.org \
--cc=edumazet@google.com \
--cc=herbert@gondor.apana.org.au \
--cc=kuba@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=steffen.klassert@secunet.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.