[6.12.y] Please backport 8045c0df98d4 ("xfrm: Fix dev use-after-free in xfrm async resumption")

[6.12.y] Please backport 8045c0df98d4 ("xfrm: Fix dev use-after-free in xfrm async resumption")

[Kusuma DS]

Hi,

6.12.y picked up a bug without its fix. Details below; the request is to queue
8045c0df98d4 for linux-6.12.y.

The issue: on every packet whose ESP decrypt goes async, dev_hold() is taken on
the ingress device but dev_put() lands on the VTI, because vti_rcv_cb reassigns
skb->dev without taking a reference. The VTI refcount is driven negative during
normal traffic, and a later `ip tunnel del` then hangs forever in
netdev_wait_allrefs_any(). The process is stuck in D state, unkillable, and the
netdev is pinned for the rest of the boot.

Introduced in 6.12.y by:

    4236c30b437b ("xfrm: hold dev ref until after transport_finish NF_HOOK")
    = mainline 1c428b038400, backported 2026-06-19, first in v6.12.94,
    together with its dependency af4b8c5e9d6d

Fixed upstream by:

    8045c0df98d4 ("xfrm: Fix dev use-after-free in xfrm async resumption")
    Fixes: 1c428b038400
    mainline v7.2-rc1; in 7.1.y as 63a300151999

The fix was not queued alongside the commit it fixes, and is still absent from
6.12.y as of v6.12.111. So every 6.12.94+ kernel carries the bug.

Confirmed on 6.12.96+deb13-cloud-amd64 with a strongSwan tunnel-mode IPsec VTI
under inbound load; kernels up to 6.12.93 do not contain the code and are
unaffected.

The fix touches only net/xfrm/xfrm_input.c, net/ipv4/xfrm4_input.c and
net/ipv6/xfrm6_input.c, against code 6.12.y already has, so it should apply
cleanly. I can test a 6.12.y-rc against the reproducer if useful.


Thanks,
Kusuma DS
Alkira Networks

Re: [6.12.y] Please backport 8045c0df98d4 ("xfrm: Fix dev use-after-free in xfrm async resumption")

[Greg KH]

On Wed, Sep 23, 2026 at 01:23:01PM +0530, Kusuma DS wrote:
> Hi,
> 
> 6.12.y picked up a bug without its fix. Details below; the request is to queue
> 8045c0df98d4 for linux-6.12.y.
> 
> The issue: on every packet whose ESP decrypt goes async, dev_hold() is taken on
> the ingress device but dev_put() lands on the VTI, because vti_rcv_cb reassigns
> skb->dev without taking a reference. The VTI refcount is driven negative during
> normal traffic, and a later `ip tunnel del` then hangs forever in
> netdev_wait_allrefs_any(). The process is stuck in D state, unkillable, and the
> netdev is pinned for the rest of the boot.
> 
> Introduced in 6.12.y by:
> 
>     4236c30b437b ("xfrm: hold dev ref until after transport_finish NF_HOOK")
>     = mainline 1c428b038400, backported 2026-06-19, first in v6.12.94,
>     together with its dependency af4b8c5e9d6d
> 
> Fixed upstream by:
> 
>     8045c0df98d4 ("xfrm: Fix dev use-after-free in xfrm async resumption")
>     Fixes: 1c428b038400
>     mainline v7.2-rc1; in 7.1.y as 63a300151999
> 
> The fix was not queued alongside the commit it fixes, and is still absent from
> 6.12.y as of v6.12.111. So every 6.12.94+ kernel carries the bug.
> 
> Confirmed on 6.12.96+deb13-cloud-amd64 with a strongSwan tunnel-mode IPsec VTI
> under inbound load; kernels up to 6.12.93 do not contain the code and are
> unaffected.
> 
> The fix touches only net/xfrm/xfrm_input.c, net/ipv4/xfrm4_input.c and
> net/ipv6/xfrm6_input.c, against code 6.12.y already has, so it should apply
> cleanly. I can test a 6.12.y-rc against the reproducer if useful.

It does not apply cleanly.  Please send a working and tested version if
you wish to have this applied.

thanks,

greg k-h

Re: [6.12.y] Please backport 8045c0df98d4 ("xfrm: Fix dev use-after-free in xfrm async resumption")

[Kusuma DS]

Hi Greg,

Thanks for replying.

You're right - I had not checked whether it applies cleanly, I only saw the
change was small. My mistake.

Is anything planned for bringing this into 6.12.y, or does it need a tested
backport first?

Thanks,
Kusuma D S
Alkira Networks



On Wed, Sep 23, 2026 at 3:02 PM Greg KH <gregkh@linuxfoundation.org> wrote:
>
> On Wed, Sep 23, 2026 at 01:23:01PM +0530, Kusuma DS wrote:
> > Hi,
> >
> > 6.12.y picked up a bug without its fix. Details below; the request is to queue
> > 8045c0df98d4 for linux-6.12.y.
> >
> > The issue: on every packet whose ESP decrypt goes async, dev_hold() is taken on
> > the ingress device but dev_put() lands on the VTI, because vti_rcv_cb reassigns
> > skb->dev without taking a reference. The VTI refcount is driven negative during
> > normal traffic, and a later `ip tunnel del` then hangs forever in
> > netdev_wait_allrefs_any(). The process is stuck in D state, unkillable, and the
> > netdev is pinned for the rest of the boot.
> >
> > Introduced in 6.12.y by:
> >
> >     4236c30b437b ("xfrm: hold dev ref until after transport_finish NF_HOOK")
> >     = mainline 1c428b038400, backported 2026-06-19, first in v6.12.94,
> >     together with its dependency af4b8c5e9d6d
> >
> > Fixed upstream by:
> >
> >     8045c0df98d4 ("xfrm: Fix dev use-after-free in xfrm async resumption")
> >     Fixes: 1c428b038400
> >     mainline v7.2-rc1; in 7.1.y as 63a300151999
> >
> > The fix was not queued alongside the commit it fixes, and is still absent from
> > 6.12.y as of v6.12.111. So every 6.12.94+ kernel carries the bug.
> >
> > Confirmed on 6.12.96+deb13-cloud-amd64 with a strongSwan tunnel-mode IPsec VTI
> > under inbound load; kernels up to 6.12.93 do not contain the code and are
> > unaffected.
> >
> > The fix touches only net/xfrm/xfrm_input.c, net/ipv4/xfrm4_input.c and
> > net/ipv6/xfrm6_input.c, against code 6.12.y already has, so it should apply
> > cleanly. I can test a 6.12.y-rc against the reproducer if useful.
>
> It does not apply cleanly.  Please send a working and tested version if
> you wish to have this applied.
>
> thanks,
>
> greg k-h

Re: [6.12.y] Please backport 8045c0df98d4 ("xfrm: Fix dev use-after-free in xfrm async resumption")

[Greg KH]

On Wed, Sep 23, 2026 at 03:26:31PM +0530, Kusuma DS wrote:
> Hi Greg,
> 
> Thanks for replying.
> 
> You're right - I had not checked whether it applies cleanly, I only saw the
> change was small. My mistake.
> 
> Is anything planned for bringing this into 6.12.y, or does it need a tested
> backport first?

As I stated (which is the problem with top-posting):

> > Please send a working and tested version if
> > you wish to have this applied.

thanks,

greg k-h

Re: [6.12.y] Please backport 8045c0df98d4 ("xfrm: Fix dev use-after-free in xfrm async resumption")

[Sasha Levin]

> > Is anything planned for bringing this into 6.12.y, or does it need a tested
> > backport first?
>
> As I stated (which is the problem with top-posting):
>
> > > Please send a working and tested version if
> > > you wish to have this applied.

I've queued my 6.12.y backport series for this, so 6.12 is covered now:

  https://lore.kernel.org/stable/20260922164842.3125154-1-sashal@kernel.org/

-- 
Thanks,
Sasha