Re: [PATCH 6.12.y v2] xfrm: hold dev ref until after transport_finish NF_HOOK

[Sasha Levin <sashal@kernel.org>]

On Thu, Jun 11, 2026 at 11:26:20AM -0400, Sasha Levin wrote:
>On Thu, Jun 11, 2026 at 12:11:27PM +0000, Simon Liebold wrote:
>> [ Upstream commit 1c428b03840094410c5fb6a5db30640486bbbfcb ]
>>
>> After async crypto completes, xfrm_input_resume() calls dev_put()
>> immediately on re-entry before the skb reaches transport_finish.
>
>Queued for 6.12, thanks.

Ugh... Looking at it again, I've dropped it.

The problem is the assumption that "the dev_put in the encap_type == -1
async-resumption block does not exist" in 6.12.y. It's true there is no dev_put
inside the 'if (encap_type == -1)' block, but that is only because the early
drop lives somewhere else here: it's the dev_put right at the 'resume:' label.

Look at where 'resume:' sits relative to the per-iteration dev_put:

   mainline (post-fix):              6.12.y:
         dev_hold(skb->dev);               dev_hold(skb->dev);
         nexthdr = ...input(x, skb);       nexthdr = ...input(x, skb);
         if (nexthdr == -EINPROGRESS) {    if (nexthdr == -EINPROGRESS)
                 if (async)                        return 0;
                         dev_put(...);     resume:
                 return 0;                         dev_put(skb->dev);   <-- early drop
         }
         dev_put(skb->dev);
   resume:                                 [async re-entry does goto resume,
         ...                                so this dev_put runs immediately]

In mainline the fix works because 'resume:' is *after* the per-iteration
dev_put, so when xfrm_input_resume() re-enters and does 'goto resume', the
async ref taken at the loop-top dev_hold is *not* dropped - it is held
continuously until after the NF_HOOK (plus the inline 'if (async) dev_put()' it
adds at the decaps/gro/drop/secondary-EINPROGRESS exits).

In 6.12.y 'resume:' is *before* that dev_put, so the async 'goto resume' hits
'dev_put(skb->dev)' straight away and drops the ref at the very start of resume
processing. The fresh 'dev_hold(skb->dev)' added before transport_finish does
not save it:

   - between the early dev_put and the re-hold, skb->dev is held by no
     xfrm reference at all - the exact window device teardown can race; and
   - 'dev_hold(skb->dev)' itself dereferences skb->dev to bump the
     refcount, so if the device was already freed in that window the
     re-hold is itself a use-after-free.

So this is a lifetime bug, not a refcount-balance bug: every hold still has a
matching put, but the reference no longer covers the critical window.

-- 
Thanks,
Sasha