Linux kernel (net/xfrm): XFRM_MSG_NEWAE lets a caller update replay-window state on a state that never had replay_esn

Impact

XFRM_MSG_NEWAE lets a caller update replay-window state on a state that never had replay_esn allocated, so the kernel memcpys into a NULL pointer. The commit is explicit that a malicious user can crash the kernel this way - a container-triggerable node panic straight through the replay-state update path.

Who can reach it

xfrm_new_ae over xfrm netlink, requiring CAP_NET_ADMIN in the network namespace - satisfied by any container granted NET_ADMIN with its own netns, and by the node's IKE daemon. No fabric access or device node needed; the SA does not need to be a valid ESN state, which is the whole point.

What to do

Boot a kernel carrying the linked stable commits. Interim: drop CAP_NET_ADMIN from tenant containers so xfrm netlink is not reachable from tenant workloads.

References

Related entries

• Linux kernel (net/xfrm): An SA created with an AF_UNSPEC selector escaped prefix-length validation, and the kernel thenCVE-2024-50142 · Linux kernel (net/xfrm)Medium
• Linux kernel (net/xfrm): The async-event reply buffer was sized without accounting for the interface-ID attribute, soCVE-2026-43107 · Linux kernel (net/xfrm)Medium
• Linux kernel (net/xfrm): Tearing down an IPTFS security association cancels its hrtimers while holding the very locksCVE-2026-53197 · Linux kernel (net/xfrm)Medium
• Linux kernel (net/xfrm): The policy-hash rebuild preallocates for exactly the wrong half of the policy set - the guardCVE-2026-64579 · Linux kernel (net/xfrm)Medium
• Linux kernel (net/xfrm): Transmitting a packet carrying a metadata dst (no dstCVE-2022-50004 · Linux kernel (net/xfrm)Medium
• Linux kernel (net/xfrm): Transport-mode IPsec packets were reinjected in the same execution context instead of beingCVE-2022-50445 · Linux kernel (net/xfrm)Medium