Linux Kernel xfrm Input State Pointer Dereferenced After VTI/XFRM Interface Resets the Security Path, Yielding a Use-After-Free

Status: UPDATED  |  Advisory ID: CVE-2026-98229

Key Details

Affected Products, Subsystems & Sectors

What to Know

In the Linux kernel, the following vulnerability has been resolved:

xfrm: save input state data before secpath resets

xfrm_input() stores the current xfrm_state in the skb secpath while it

continues receive-side processing. Some input paths can reset that secpath

before xfrm_input() 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 XFRM_MAX_DEPTH error path can also

reset the secpath before the final drop callback reports the current

state's protocol.

If secpath_reset() drops the last state reference while the state is

concurrently deleted, xfrm_input() can still dereference the freed state

when selecting transport_finish() 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 transport_finish(). A larval

XFRM_STATE_ACQ 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. (NVD)

What to Do

Monitor Linux's web page for any future patch releases.

References