2026-09-21, 22:43:59 +0200, Antony Antony wrote:
> While looking into a XFRM_MSG_MIGRATE_STATE issue reported by Sashiko,
> we found the underlying problem generalizes: xfrm allows multiple SAs
> to coexist for the same (SPI, daddr, proto) differing only in mark,
> and every netlink method that resolves "which SA" - xfrm get_sa(),
> del_sa(), update, get_ae, new_ae, expire, migrate - uses the same
> wildcard mark match the data path needs. A broader-mask SA can
> silently shadow a more specific one:
>
> # ip xfrm state add ... spi 0x1000 mark 1 mask 1 (SA_target)
> # ip xfrm state add ... spi 0x1000 mark 0 mask 0
> (SA_decoy, catch-all, added after -> bucket head)
> # ip xfrm state delete dst ... proto esp spi 0x1000 mark 1 mask 1
> -> deletes SA_decoy; SA_target survives, untouched
>
> xfrm policy had the same bug, fixed in commit 4f47e8ab6ab7
> ("xfrm: policy: match with both mark and mask on user interfaces").
>
> Netlink lookups use an exact mark/mask match except for UPDSA; the
> wildcard match stays for the data path and state_add only.
> This series applies that fix across every affected method,
> not just XFRM_MSG_MIGRATE_STATE.
>
> This series is not fixing likely isusses PF_KEY. As it
> is no more receiving non critical fixes.
The series looks good, but why did you remove the selftests you had in v1?
https://lore.kernel.org/all/[email protected]/
--
Sabrina
