public inbox for netdev@vger.kernel.org
 help / color / mirror / Atom feed
From: Simon Horman <horms@kernel.org>
To: antony.antony@secunet.com
Cc: Simon Horman <horms@kernel.org>,
	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: [ipsec-next,v6,12/14] xfrm: add XFRM_MSG_MIGRATE_STATE for single SA migration
Date: Wed, 11 Mar 2026 19:57:31 +0000	[thread overview]
Message-ID: <20260311195731.1147919-1-horms@kernel.org> (raw)
In-Reply-To: <migrate-state-v6-12-9df9764ddb9e@secunet.com>

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?

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];
    ...
    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?

  reply	other threads:[~2026-03-11 19:57 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   ` Simon Horman [this message]
2026-03-11 20:43     ` [devel-ipsec] Re: [ipsec-next,v6,12/14] " Antony Antony
2026-03-12 16:41       ` 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=20260311195731.1147919-1-horms@kernel.org \
    --to=horms@kernel.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=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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox