CVE-2026-98229: xfrm: save input state data before secpath resets
In the Linux kernel, the following vulnerability has been resolved:
xfrm: save input state data before secpath resets
xfrminput() stores the current xfrmstate in the skb secpath while it continues receive-side processing. Some input paths can reset that secpath before xfrminput() has finished dereferencing the state.
Receive callback users such as VTI and XFRM interfaces can reset the secpath. The VTI receive path does so before checking whether the packet crosses network namespaces, while the XFRM interface path does so only for cross-network-namespace packets. The XFRMMAXDEPTH error path can also reset the secpath before the final drop callback reports the current state's protocol.
If secpathreset() drops the last state reference while the state is concurrently deleted, xfrminput() can still dereference the freed state when selecting transportfinish() or reporting the drop callback protocol.
Save the state protocol on the stack while the state is still valid, and use the already saved address family for transportfinish(). A larval XFRMSTATEACQ state has no type, so retain nexthdr as its protocol. This preserves the existing drop-path fallback while avoiding the post-reset state dereferences without adding an extra state reference to every received packet.
Affected Software
Event History
Frequently Asked Questions
Which deployments are most exposed to this issue?
Systems using VTI receive processing or XFRM interfaces are the relevant exposure cases. VTI can reset the security path before checking network-namespace crossing, while XFRM interfaces do so for packets crossing network namespaces.
What conditions are involved in triggering the use-after-free?
A receive-side path must reset the packet's secpath while xfrm_input() still needs the current xfrm_state, and the last state reference must be dropped while that state is concurrently deleted. The XFRM_MAX_DEPTH error path can also reset secpath before the final drop callback uses the state's protocol.
Are larval XFRM acquisition states handled differently by the fix?
Yes. A larval XFRM_STATE_ACQ state has no type, so the fix retains nexthdr as its protocol to preserve the existing drop-path fallback.