Re: [PATCH net v4 1/1] xfrm: save input state data before secpath resets

[Steffen Klassert <steffen.klassert@secunet.com>]

On Sat, Aug 29, 2026 at 05:24:24PM +0800, Zhiling Zou wrote:
> 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.
> 
> Fixes: df3893c176e9 ("vti: Update the ipv4 side to use it's own receive hook.")
> Cc: stable@vger.kernel.org
> Reported-by: Vega <vega@nebusec.ai>
> Signed-off-by: Zhiling Zou <zhilinz@nebusec.ai>

Patch applied, thanks a lot!