Re: [PATCH 0/18] pull request (net-next): ipsec-next 2026-06-12

[Antony Antony <antony@phenome.org>]

Hi Yan,

thanks for testing. Would you please test on a new series?

On Thu, Jun 25, 2026 at 06:58:47PM -0700, Yan Yan wrote:
> Hi Antony,
> 
> I ran the following test cases and two—4.2 and 6—are worth disucssing:
> 
> 1.  Mark Inheritance: Creates one SA and migrates it without
> specifying a new mark. [PASSED]
> 2.  Mark Update: Creates one SA with a specific mark and migrates it
> to a new specific mark. [PASSED]
> 3.  State Update Isolation: Creates two SAs differing only by mark and
> verifies that migrating one does not affect the other. [PASSED]
> 4.  Mark Collision:
>     4.1 [Specific Mark] Creates two SAs differing only by mark: SA
> (mark_1) and an SA (mark_2). Verifies migrating SA (mark_1) to mark_2
> fails with EEXIST and both SAs intact. [PASSED]
>     4.2 [Wildcard Mark] Creates two SAs differing only by mark: SA
> (mark_1) and an SA (mark_none). Migrate the mark_none to mark_1.
> Expecting failure with EEXIST and both SAs intact. [FAILED: SA
> (mark_none) ends up being deleted]
> 5.  Mark Mismatch:
>     5.1 Creates only a wildcard SA and verifying migration using a
> specific mark fails with ESRCH; SA intact [PASSED]
>     5.2 Creates only one SA (mark_1) and verifying migration using a
> mark_2 fails with ESRCH; SA intact [PASSED]
> 6.  Mark Shadowing Failure:: Creates two SAs differing only by mark:
> the first SA (mark_1) and the second SA (mark None). Migrating the SA
> (mark_1) fails with ESRCH, two SAs remain untouched [PASSED]
> 
> --------------------------------
> My questions are as follows:
> 
> Regarding 4.2 I believe is a kernel bug. During the pre-migration
> collision check, the lookup for the mark_1 matches the wildcard SA
> itself first, causing the kernel to miss the collision with the
> existing specific SA with mark_1
> 
> At https://github.com/antonyantony/linux/blob/migrate-state-fixes-v0/net/xfrm/xfrm_user.c#L3450
> 
> x_new = xfrm_state_lookup(net, new_mark_key, &m.new_daddr, ----> BUG:
> We are looking for the existence of SA (mark_1) but SA (mark_none) is
> returned.
> um->id.spi, um->id.proto, m.new_family);
> if (x_new) {
>     xfrm_state_put(x_new);
>     if (x_new != x) { ----> BUG: We end up having x_new == x
>     NL_SET_ERR_MSG(extack, "New SA tuple already occupied");
>     err = -EEXIST;
>     goto out;
> }
this should be fixed no. Would please try again?


> /* self-match via wide mark mask; not a collision */
> 
> Would it be possible to traverse the entire list or create a lookup
> method for an exact match?
> 
> Regarding  6.  I wrote the tests as per the kernel implementation but
> I'm not sure it is intended. Intuitively, this migration should
> succeed by finding and updating the specific SA (mark_1) instead of
> failing. Is this failure considered an acceptable limit, or should we
> aim to support exact-match lookup here?


While trying to fix MIGRATE_STATE I fell into a rabbit hole:)
I realized many methods have this issue. Just never noticed, as it would be
a misconfiguration, and would likely cause operational issues rather than 
crashes.
However, given that xfrm accepts multiple identical SAs differing only in mark,
a proper fix is to add __xfrm_state_locate_exact() for both spi and byaddr 
lookups.  This should be used in all calls from userspace.

I just send a new series.
https://patchwork.kernel.org/project/netdevbpf/patch/migrate-state-fixes-v0-1-a69e8637ba3b@secunet.com/

-antony