Re: [PATCH net 1/2] vti: fix tunnel device use-after-free across async crypto resumption

[Qihang]

Hi Steffen,

Thanks a lot for the guidance, much appreciated.

Your three points make sense. For IPTFS, the skbs freed without the
receive callback are the outer xfrm skbs, and it's only a handful of
places in xfrm_iptfs.c -- a small shared helper would be cleaner than
open-coding it at each site.  The two xfrm_input changes (set family
before the early drop, and hold the skb->dev reference unconditionally)
look straightforward too.

Would you prefer to handle the IPTFS and xfrm_input fixes yourself
(Christian for IPTFS?), or should I send them as part of this series?
Either way is fine with me.

Thanks again,
Qihang

On Mon, Oct 12, 2026 at 3:54 PM Steffen Klassert
<steffen.klassert@xxxxxxxxxxx> wrote:
>
> On Thu, Oct 08, 2026 at 01:49:16AM +0000, Qihang wrote:
> > All real, and vti6 has the same problems.
> >
> > The dev_hold()/dev_put() idea assumed the callback runs exactly once
> > per skb, which xfrm_input() doesn't guarantee. IPTFS frees the outer
> > skb on its own without any callback.
>
> This is a IPTFS bug. If IPTFS frees the skb, it has to make sure
> to run the whole destruction path including all the callbacks.
>
> > The early drop when the SA is no
> > longer valid happens while family is still AF_UNSPEC, so xfrm_rcv_cb()
> > can't find the afinfo and never calls us.
>
> Assigning family before the early drop should fix this.
>
> > And on the success path I'd
> > drop the last reference before gro_cells_receive() is done with
> > skb->dev.
>
> I think we should unconditionally refcount skb->dev in the
> xfrm input path to fix that for now.
>