All of lore.kernel.org
 help / color / mirror / Atom feed
From: Antony Antony <antony@phenome.org>
To: Simon Horman <horms@kernel.org>
Cc: antony.antony@secunet.com, evitayan@google.com,
	linux-kernel@vger.kernel.org, kuba@kernel.org, pabeni@redhat.com,
	herbert@gondor.apana.org.au, paul@paul-moore.com,
	devel@linux-ipsec.org, davem@davemloft.net, nakam@linux-ipv6.org,
	netdev@vger.kernel.org, edumazet@google.com,
	stephen.smalley.work@gmail.com, steffen.klassert@secunet.com,
	selinux@vger.kernel.org, linux-doc@vger.kernel.org,
	chiachangwang@google.com, omosnace@redhat.com, corbet@lwn.net,
	dsahern@kernel.org, skhan@linuxfoundation.org
Subject: Re: [devel-ipsec] Re: [ipsec-next,v6,12/14] xfrm: add XFRM_MSG_MIGRATE_STATE for single SA migration
Date: Wed, 11 Mar 2026 21:43:04 +0100	[thread overview]
Message-ID: <abHT2HLx-BvKnu-c@Antony2201.local> (raw)
In-Reply-To: <20260311195731.1147919-1-horms@kernel.org>

Hi Simon,

On Wed, Mar 11, 2026 at 07:57:31PM +0000, Simon Horman via Devel wrote:
> This is an AI-generated review of your patch. The human sending this
> email has considered the AI review valid, or at least plausible.
> 
> For local reproduction steps see https://netdev-ai.bots.linux.dev/ai-local.html
> ---
> xfrm: add XFRM_MSG_MIGRATE_STATE for single SA migration
> 
> This patch adds a new netlink method to migrate a single xfrm_state.
> Unlike the existing migration mechanism (SA + policy), this supports
> migrating only the SA and allows changing the reqid.
> 
> > diff --git a/include/net/xfrm.h b/include/net/xfrm.h
> > index 4b29ab92c2a7..ae2a1cf2311a 100644
> > --- a/include/net/xfrm.h
> > +++ b/include/net/xfrm.h
> > @@ -683,11 +683,17 @@ struct xfrm_migrate {
> >  	xfrm_address_t		new_daddr;
> >  	xfrm_address_t		new_saddr;
> >  	struct xfrm_encap_tmpl *encap;
> > -	struct xfrm_user_offload *xuo;
> > +	struct xfrm_user_offload xuo;
> 
> [ ... ]
> 
> > diff --git a/net/xfrm/xfrm_policy.c b/net/xfrm/xfrm_policy.c
> > index 2f23ca5b62a9..de8b038fc08c 100644
> > --- a/net/xfrm/xfrm_policy.c
> > +++ b/net/xfrm/xfrm_policy.c
> > @@ -4642,6 +4642,19 @@ static int xfrm_migrate_check(const struct xfrm_migrate *m, int num_migrate,
> >  	return 0;
> >  }
> >
> > +/* Fill migrate fields that are invariant in XFRM_MSG_MIGRATE: inherited
> > + * from the existing SA unchanged.
> > + */
> > +static void xfrm_migrate_copy_old(struct xfrm_migrate *mp,
> > +				  const struct xfrm_state *x)
> > +{
> > +	mp->smark                  = x->props.smark;
> > +	mp->new_reqid              = x->props.reqid;
> > +	mp->nat_keepalive_interval = x->nat_keepalive_interval;
> > +	mp->mapping_maxage         = x->mapping_maxage;
> > +	mp->new_mark               = x->mark;
> > +}
> > +
> >  int xfrm_migrate(const struct xfrm_selector *sel, u8 dir, u8 type,
> >  		 struct xfrm_migrate *m, int num_migrate,
> >  		 struct xfrm_kmaddress *k, struct net *net,
> > @@ -4680,7 +4693,10 @@ int xfrm_migrate(const struct xfrm_selector *sel, u8 dir, u8 type,
> >  			x_cur[nx_cur] = x;
> >  			nx_cur++;
> >  			mp->encap = encap;
> > -			mp->xuo = xuo;
> > +			if (xuo)
> > +				mp->xuo = *xuo;
>                                      ^^^^
> >  			xfrm_migrate_copy_old(mp, x);
> >
> 
> What happens to mp->xuo when xuo is NULL?

thanks. I also red this on NIPA AI reviews. I will fix it in the next 
version.

> 
> The xfrm_migrate structure changed its xuo field from a pointer
> (struct xfrm_user_offload *xuo) to an embedded value
> (struct xfrm_user_offload xuo).
> 
> In xfrm_migrate(), when the xuo parameter is NULL (PF_KEY path via
> pfkey_migrate, or XFRM_MSG_MIGRATE without XFRMA_OFFLOAD_DEV), the
> 'if (xuo) mp->xuo = *xuo' branch is skipped, leaving mp->xuo with
> uninitialized stack data.
> 
> Both callers declare 'struct xfrm_migrate m[XFRM_MAX_DEPTH]' on the
> stack without zeroing:
> 
> net/key/af_key.c:pfkey_migrate() {
>     struct xfrm_migrate m[XFRM_MAX_DEPTH];
>     ...
>     err = xfrm_migrate(&sel, dir, XFRM_POLICY_TYPE_MAIN, m, i,
>                        k.local && k.remote ? &k : NULL, net,
>                        NULL, 0, NULL);
> }
> 
> net/xfrm/xfrm_user.c:xfrm_do_migrate() {
>     struct xfrm_migrate m[XFRM_MAX_DEPTH];

-  struct xfrm_migrate m[XFRM_MAX_DEPTH];
+  struct xfrm_migrate m[XFRM_MAX_DEPTH] = {};

this should fix it.

>     ...
>     err = xfrm_migrate(&sel, dir, type, m, n, k, net, encap, xuo, extack);
> }
> 
> The uninitialized mp->xuo.ifindex is later read in
> xfrm_state_migrate_create() and xfrm_state_migrate_install():
> 
> net/xfrm/xfrm_state.c:xfrm_state_migrate_create() {
>     ...
>     /* configure the hardware if offload is requested */
>     if (m->xuo.ifindex && xfrm_dev_state_add(net, xc, &m->xuo, extack))
>         goto error;
> }
> 
> net/xfrm/xfrm_state.c:xfrm_state_migrate_install() {
>     ...
>     if (xfrm_state_add(xc) < 0) {
>         NL_SET_ERR_MSG(extack, "Failed to add migrated state");
>         if (m->xuo.ifindex)
>             xfrm_dev_state_delete(xc);
>         ...
>     }
> }
> 
> If the stack garbage contains a non-zero ifindex value,
> xfrm_dev_state_add() will be called with random ifindex and flags,
> potentially causing spurious hardware offload attempts or migration
> failures.
> 
> Previously, 'mp->xuo = xuo' unconditionally set the pointer to NULL in
> these paths, which was then properly checked as 'if (m->xuo)'.
> 
> Should mp->xuo be zero-initialized when xuo is NULL, either by adding
> 'else memset(&mp->xuo, 0, sizeof(mp->xuo))' after the if-block, or by
> zero-initializing the m[] arrays in the callers?

thanks,
-antony

  reply	other threads:[~2026-03-11 20:43 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-09 18:43 [PATCH ipsec-next v6 00/14] xfrm: XFRM_MSG_MIGRATE_STATE new netlink message Antony Antony
2026-03-09 18:44 ` [PATCH ipsec-next v6 01/14] xfrm: remove redundant assignments Antony Antony
2026-03-09 18:45 ` [PATCH ipsec-next v6 02/14] xfrm: add extack to xfrm_init_state Antony Antony
2026-03-09 18:45 ` [PATCH ipsec-next v6 03/14] xfrm: allow migration from UDP encapsulated to non-encapsulated ESP Antony Antony
2026-03-09 18:45 ` [PATCH ipsec-next v6 04/14] xfrm: fix NAT-related field inheritance in SA migration Antony Antony
2026-03-09 18:46 ` [PATCH ipsec-next v6 05/14] xfrm: rename reqid in xfrm_migrate Antony Antony
2026-03-09 18:46 ` [PATCH ipsec-next v6 06/14] xfrm: split xfrm_state_migrate into create and install functions Antony Antony
2026-03-09 18:46 ` [PATCH ipsec-next v6 07/14] xfrm: check family before comparing addresses in migrate Antony Antony
2026-03-09 18:46 ` [PATCH ipsec-next v6 08/14] xfrm: add state synchronization after migration Antony Antony
2026-03-09 18:46 ` [PATCH ipsec-next v6 09/14] xfrm: add error messages to state migration Antony Antony
2026-03-09 18:46 ` [PATCH ipsec-next v6 10/14] xfrm: move encap and xuo into struct xfrm_migrate Antony Antony
2026-03-09 18:47 ` [PATCH ipsec-next v6 11/14] xfrm: refactor XFRMA_MTIMER_THRESH validation into a helper Antony Antony
2026-03-09 18:47 ` [PATCH ipsec-next v6 12/14] xfrm: add XFRM_MSG_MIGRATE_STATE for single SA migration Antony Antony
2026-03-11 19:57   ` [ipsec-next,v6,12/14] " Simon Horman
2026-03-11 20:43     ` Antony Antony [this message]
2026-03-12 16:41       ` [devel-ipsec] " Simon Horman
2026-03-09 18:47 ` [PATCH ipsec-next v6 13/14] xfrm: restrict netlink attributes for XFRM_MSG_MIGRATE_STATE Antony Antony
2026-03-09 18:47 ` [PATCH ipsec-next v6 14/14] xfrm: docs: add documentation " 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=abHT2HLx-BvKnu-c@Antony2201.local \
    --to=antony@phenome.org \
    --cc=antony.antony@secunet.com \
    --cc=chiachangwang@google.com \
    --cc=corbet@lwn.net \
    --cc=davem@davemloft.net \
    --cc=devel@linux-ipsec.org \
    --cc=dsahern@kernel.org \
    --cc=edumazet@google.com \
    --cc=evitayan@google.com \
    --cc=herbert@gondor.apana.org.au \
    --cc=horms@kernel.org \
    --cc=kuba@kernel.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nakam@linux-ipv6.org \
    --cc=netdev@vger.kernel.org \
    --cc=omosnace@redhat.com \
    --cc=pabeni@redhat.com \
    --cc=paul@paul-moore.com \
    --cc=selinux@vger.kernel.org \
    --cc=skhan@linuxfoundation.org \
    --cc=steffen.klassert@secunet.com \
    --cc=stephen.smalley.work@gmail.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.