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

[Antony Antony <antony@phenome.org>]

On Tue, Jun 16, 2026 at 07:54:29AM +0200, Antony Antony wrote:
> On Sat, Jun 13, 2026 at 01:15:52PM -0700, Jakub Kicinski wrote:
> > On Fri, 12 Jun 2026 09:46:16 +0200 Steffen Klassert wrote:
> > > 3) Add a new netlink message XFRM_MSG_MIGRATE_STATE that
> > >    allows migrating individual IPsec SAs independently of
> > >    their policies. The existing XFRM_MSG_MIGRATE is tightly coupled
> > >    to policy+SA migration, lacks SPI for unique SA identification,
> > >    and cannot express reqid changes or migrate Transport mode
> > >    selectors. The new interface identifies the SA via SPI and mark,
> > >    supports reqid changes, address family changes, encap removal,
> > >    and uses an atomic create+install flow under x->lock to prevent
> > >    SN/IV reuse during AEAD SA migration.
> > >    From Antony Antony.
> > 
> > Hi! There are some Sashiko comments here, please follow up:
> > 
> > https://sashiko.dev/#/patchset/20260612074725.1760473-8-steffen.klassert@secunet.com
> > 
> 
> Thanks Jakub. I have fixes and testing them now. And I will send fixes soon.
> 
> The comments didn't click until I realized xfrm_user_state_lookup() only
> keys on mark.v & mark.m, so distinct (v, m) pairs collapse to the same
> masked value. A lookup key of {0, 0} matches a source SA with mark
> {0, 0xffffff} (both mask to 0), but reusing {0, 0} as the migrated mark 
> turns "match only mark 0x00" into "match all traffic".
> 
> Fix is copy from old SA than from old_mark passed along. This also pointed 
> more issues.

I have fixes queued up for the issues Sashiko found, to send once the
ipsec tree has net-next. What Sashiko pointed are corner cases. IMO
a typical IKE/IPsec daemon would not trigger, but worth fixing. 

The fixes address all four High findings and the Medium in patch 16/18.
Finding 6 (patch 05/18, encap removal) was determined to be a false
positive — already reviewed.

One tricky part worth noting: xfrm allows two SAs with the same SPI,
src, dst, and proto, however different mark:

  ip xfrm state add src 10.1.1.1 dst 10.1.1.2 spi 0x1000 .. mark 0x1 mask 0xff
  ip xfrm state add src 10.1.1.1 dst 10.1.1.2 spi 0x1000 .. mark 0x2 mask 0xff

  ip x s
  src 10.1.1.1 dst 10.1.1.2
      proto esp spi 0x00001000 reqid 100 mode tunnel
      replay-window 0
      mark 0x2/0xff
      aead rfc4106(gcm(aes)) 0x1111111111111111111111111111111111111111 96
      anti-replay context: seq 0x0, oseq 0x0, bitmap 0x00000000
      sel src 0.0.0.0/0 dst 0.0.0.0/0
  src 10.1.1.1 dst 10.1.1.2
      proto esp spi 0x00001000 reqid 100 mode tunnel
      replay-window 0
      mark 0x1/0xff
      aead rfc4106(gcm(aes)) 0x1111111111111111111111111111111111111111 96
      anti-replay context: seq 0x0, oseq 0x0, bitmap 0x00000000
      sel src 0.0.0.0/0 dst 0.0.0.0/0

Both are accepted: same SPI 0x1000, two distinct SAs with diffrent
mark. Note that both SAs share the same key material and their
independent oseq counters both start at 0 - the encrypted packets
from each produces an identical AES-GCM IV.

Does anyone know whether this is intentional or accidental? Is there a
use case that requires two SAs with identical crypto and replay counter,
however, different marks?

This is also what makes state migration with Mark complex. Since xfrm
permits two SAs to share the same SPI with different marks, migrating
a mark must check whether the target slot is already occupied.
The fix "xfrm: check mark changes for SA tuple collisions in XFRM_MSG_MIGRATE_STATE" does
exactly that, using the effective lookup key m->v & m->m to detect a
collision before proceeding.

Kernel selftests for this series are included in the tree. However,
extensive testing is difficult on my end — *swan cannot easily create
these cases.

Yan/Nathan,
would you be able to run the Android test suite against this branch? to
test migrating SA with mark set.

https://github.com/antonyantony/linux/tree/migrate-state-fixes-v0

-antony