CVE-2026-63914: xfrm: route MIGRATE notifications to caller's netns
In the Linux kernel, the following vulnerability has been resolved:
xfrm: route MIGRATE notifications to caller's netns
xfrmsendmigrate() in net/xfrm/xfrmuser.c and pfkeysendmigrate() in net/key/afkey.c both hardcode &initnet for the multicast that announces a successful XFRMMSGMIGRATE / SADBXMIGRATE.
XFRMMSGMIGRATE arrives on a per-netns NETLINKXFRM socket, and the rest of the xfrm/afkey netlink path was made netns-aware in 2008. The other 14 multicast paths in xfrmuser.c route their event using xsnet(x), xpnet(xp) or socknet(skb->sk); only the migrate path was missed.
Two consequences of the initnet hardcoding:
1. The notification (selector, old/new endpoint addresses, and the kmaddress) is delivered to listeners on initnet's XFRMNLGRPMIGRATE / pfkey BROADCASTALL groups rather than on the issuing netns. An IKE daemon running in initnet therefore receives migration notifications originating from any other netns on the host.
2. An IKE daemon running inside a non-init netns and subscribed to its own XFRMNLGRPMIGRATE / pfkey groups never receives the notification of its own migration. IKEv2 MOBIKE / address-update handling inside a netns is silently broken.
Thread struct net through kmmigrate() and the xfrmmgr.migrate function pointer, drop the &initnet override in xfrmsendmigrate() and pfkeysendmigrate(), and pass the caller's net (already in scope in xfrmmigrate() via socknet(skb->sk)) all the way down. struct xfrmmgr is in-tree only and not exported as a stable API, so the function-pointer signature change is internal.
pfkeybroadcast() is already netns-aware via netgeneric(net, pfkeynetid) since the pernet conversion. The five other pfkeybroadcast() callers in afkey.c already pass xsnet(x), socknet(sk) or a per-netns net, so this only removes the &initnet outlier.
Affected Software
Event History
Frequently Asked Questions
Who is affected by this issue in practice?
Hosts that use XFRM or PF_KEY migration notifications across network namespaces are affected. An IKE daemon in the initial network namespace can receive migration details from other namespaces, while an IKE daemon in a non-initial namespace can miss notifications for its own migrations.
What access is needed to trigger the problem?
The CVSS vector indicates local access with low privileges and no user interaction. The issue is triggered through successful XFRM_MSG_MIGRATE or SADB_X_MIGRATE migration handling involving network namespaces.
What information may be exposed?
Migration notifications sent to listeners in the initial network namespace include the selector, old and new endpoint addresses, and km_address. This can disclose migration information originating from another network namespace to an IKE daemon listening in the initial namespace.
How can I tell whether an IKE daemon is affected?
An IKE daemon in a non-initial network namespace that subscribes to its local XFRMNLGRP_MIGRATE or PF_KEY broadcast group will not receive its own migration notification. Conversely, an initial-namespace listener may receive notifications for migrations issued from other namespaces.