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

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

[Qihang]

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. 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. And on the success path I'd
drop the last reference before gro_cells_receive() is done with
skb->dev.

So I'll drop this. Two options I can see for the respin:

Re-lookup the tunnel in the callback like xfrmi does. The only key I
have there is the outer addresses of the state, which won't reproduce
the original lookup for wildcard-source SAs, and during teardown it
can pick up the fallback device instead. The RCU section also ends at
gro_cells_receive(): the skb queued to the gro cell is processed by
NAPI afterwards with skb->dev still pointing at the tunnel device and
nothing holding a reference.

Keep a reference from vti_input() but release it when the skb is freed
instead of in the callback, so the paths where the callback never runs
can't leak. That looks like it needs xfrm core support, so I'd rather
not pick it unilaterally.

Which way do you want this to go?

pw-bot: cr