In the Linux kernel, the following vulnerability has been resolved: xfrm: route MIGRATE notifications to caller's netns xfrm_send_migrate() in… (CVE-2026-63914)
In the Linux kernel, the following vulnerability has been resolved: xfrm: route MIGRATE notifications to caller's netns xfrm_send_migrate() in net/xfrm/xfrm_user.c and pfkey_send_migrate() in net/key/af_key.c both hardcode &init_net for the multicast that announces a successful XFRM_MSG_MIGRATE / SADB_X_MIGRATE. XFRM_MSG_MIGRATE arrives on a per-netns NETLINK_XFRM socket, and the rest of the xfrm/af_key netlink path was made netns-aware in 2008. The other 14 multicast paths in xfrm_user.c route their event using xs_net(x), xp_net(xp) or sock_net(skb->sk); only the migrate path was missed. Two consequences of the init_net hardcoding: 1. The notification (selector, old/new endpoint addresses, and the km_address) is delivered to listeners on init_net's XFRMNLGRP_MIGRATE / pfkey BROADCAST_ALL groups rather than on the issuing netns. An IKE daemon running in init_net 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 XFRMNLGRP_MIGRATE / 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 km_migrate() and the xfrm_mgr.migrate function pointer, drop the &init_net override in xfrm_send_migrate() and pfkey_send_migrate(), and pass the caller's net (already in scope in xfrm_migrate() via sock_net(skb->sk)) all the way down. struct xfrm_mgr is in-tree only and not exported as a stable API, so the function-pointer signature change is internal. pfkey_broadcast() is already netns-aware via net_generic(net, pfkey_net_id) since the pernet conversion. The five other pfkey_broadcast() callers in af_key.c already pass xs_net(x), sock_net(sk) or a per-netns net, so this only removes the &init_net outlier.
AI Analysis
Technical Summary
The Linux kernel's xfrm_send_migrate() and pfkey_send_migrate() functions hardcoded the &init_net network namespace for multicast notifications of XFRM_MSG_MIGRATE / SADB_X_MIGRATE events. This caused migration notifications to be delivered only to listeners in init_net, regardless of the originating network namespace. As a result, IKE daemons running in non-init network namespaces did not receive their own migration notifications, breaking address update handling for IKEv2 MOBIKE within those namespaces. The fix involved passing the caller's network namespace through the migration notification path and removing the &init_net override, ensuring notifications are correctly scoped per network namespace.
Potential Impact
IKE daemons running in the initial network namespace receive migration notifications from all namespaces, potentially causing confusion or misprocessing. More critically, IKE daemons running in non-init network namespaces do not receive their own migration notifications, causing silent failures in IKEv2 MOBIKE address update handling within those namespaces. This impacts the correct operation of IPsec key management and mobility features in containerized or multi-namespace environments.
Mitigation Recommendations
A fix has been implemented in the Linux kernel to route migration notifications to the caller's network namespace instead of the hardcoded init_net. Users should apply the official kernel update that includes this fix once available. Patch status is not explicitly stated in the provided data; therefore, check the vendor advisory or Linux kernel mailing lists for the official patch and update guidance.
In the Linux kernel, the following vulnerability has been resolved: xfrm: route MIGRATE notifications to caller's netns xfrm_send_migrate() in… (CVE-2026-63914)
Description
In the Linux kernel, the following vulnerability has been resolved: xfrm: route MIGRATE notifications to caller's netns xfrm_send_migrate() in net/xfrm/xfrm_user.c and pfkey_send_migrate() in net/key/af_key.c both hardcode &init_net for the multicast that announces a successful XFRM_MSG_MIGRATE / SADB_X_MIGRATE. XFRM_MSG_MIGRATE arrives on a per-netns NETLINK_XFRM socket, and the rest of the xfrm/af_key netlink path was made netns-aware in 2008. The other 14 multicast paths in xfrm_user.c route their event using xs_net(x), xp_net(xp) or sock_net(skb->sk); only the migrate path was missed. Two consequences of the init_net hardcoding: 1. The notification (selector, old/new endpoint addresses, and the km_address) is delivered to listeners on init_net's XFRMNLGRP_MIGRATE / pfkey BROADCAST_ALL groups rather than on the issuing netns. An IKE daemon running in init_net 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 XFRMNLGRP_MIGRATE / 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 km_migrate() and the xfrm_mgr.migrate function pointer, drop the &init_net override in xfrm_send_migrate() and pfkey_send_migrate(), and pass the caller's net (already in scope in xfrm_migrate() via sock_net(skb->sk)) all the way down. struct xfrm_mgr is in-tree only and not exported as a stable API, so the function-pointer signature change is internal. pfkey_broadcast() is already netns-aware via net_generic(net, pfkey_net_id) since the pernet conversion. The five other pfkey_broadcast() callers in af_key.c already pass xs_net(x), sock_net(sk) or a per-netns net, so this only removes the &init_net outlier.
CVSS v3.1
AI-Powered Analysis
Machine-generated threat intelligence
Technical Analysis
The Linux kernel's xfrm_send_migrate() and pfkey_send_migrate() functions hardcoded the &init_net network namespace for multicast notifications of XFRM_MSG_MIGRATE / SADB_X_MIGRATE events. This caused migration notifications to be delivered only to listeners in init_net, regardless of the originating network namespace. As a result, IKE daemons running in non-init network namespaces did not receive their own migration notifications, breaking address update handling for IKEv2 MOBIKE within those namespaces. The fix involved passing the caller's network namespace through the migration notification path and removing the &init_net override, ensuring notifications are correctly scoped per network namespace.
Potential Impact
IKE daemons running in the initial network namespace receive migration notifications from all namespaces, potentially causing confusion or misprocessing. More critically, IKE daemons running in non-init network namespaces do not receive their own migration notifications, causing silent failures in IKEv2 MOBIKE address update handling within those namespaces. This impacts the correct operation of IPsec key management and mobility features in containerized or multi-namespace environments.
Mitigation Recommendations
A fix has been implemented in the Linux kernel to route migration notifications to the caller's network namespace instead of the hardcoded init_net. Users should apply the official kernel update that includes this fix once available. Patch status is not explicitly stated in the provided data; therefore, check the vendor advisory or Linux kernel mailing lists for the official patch and update guidance.
Technical Details
- Gcve Source
- db.gcve.eu
- Osv Id
- GHSA-xcfp-8r3c-9qrj
- Osv Schema Version
- 1.4.0
- Aliases
- ["CVE-2026-63914"]
- Ecosystems
- []
- Database Specific Severity
- null
- Cvss Version
- null
Threat ID: 6a5d27ab2a4a8d598912f589
Added to database: 07/19/2026, 19:38:19 UTC
Last enriched: 07/19/2026, 20:08:36 UTC
Last updated: 07/20/2026, 19:41:22 UTC
Views: 10
Community Reviews
0 reviewsCrowdsource mitigation strategies, share intel context, and vote on the most helpful responses. Sign in to add your voice and help keep defenders ahead.
Want to contribute mitigation steps or threat intel context? Sign in or create an account to join the community discussion.
Actions
Updates to AI analysis require Pro Console access. Upgrade inside Console → Billing.
Need more coverage?
Upgrade to Pro Console for AI refresh and higher limits.
For incident response and remediation, OffSeq services can help resolve threats faster.
Latest Threats
Check if your credentials are on the dark web
Instant breach scanning across billions of leaked records. Free tier available.