[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")

[Matthias Merz]

Hello,

Please apply upstream commit 8045c0df98d4 ("xfrm: Fix dev use-after-free
in xfrm async resumption") also to 6.12.y. Stable 7.1.5 contains this in
63a300151999.

It fixes 1c428b038400 ("xfrm: hold dev ref until after transport_finish
NF_HOOK"), which is present in 6.12.y since 6.12.94. On our IPsec
gateways using xfrm interfaces this issue underflows the interface
refcount and hangs unregister_netdevice() on tunnel teardown, rekey or
system shutdown:

  unregister_netdevice: waiting for xfrm-<ifname> to become free. Usage count = -381

This leads to a complete drop of our VPN links after some hours, and
stalls the reboot for a couple of minutes waiting for devices to become
free (I remember waiting 10-15 minutes for the shutdown when remote
rebooting a gateway without physical access)

known affected: 6.12.96 and 6.12.96, known unaffected 6.12.90
Fixed in 7.1.5 via 63a300151999.

Maybe you could also consider having a look at the other longterm
releases, but I have no insight where it might apply.


Thanks,
Matthias Merz

-- 
Bei Linux geht prinzipiell alles-
den Rest nennt man Bugs. Bei Windows geht prinzipiell gar nix-
den Rest nennt man Features.

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

[Greg KH]

On Fri, Aug 07, 2026 at 04:21:55PM +0200, Matthias Merz wrote:
> Hello,
> 
> Please apply upstream commit 8045c0df98d4 ("xfrm: Fix dev use-after-free
> in xfrm async resumption") also to 6.12.y. Stable 7.1.5 contains this in
> 63a300151999.
> 
> It fixes 1c428b038400 ("xfrm: hold dev ref until after transport_finish
> NF_HOOK"), which is present in 6.12.y since 6.12.94. On our IPsec
> gateways using xfrm interfaces this issue underflows the interface
> refcount and hangs unregister_netdevice() on tunnel teardown, rekey or
> system shutdown:
> 
>   unregister_netdevice: waiting for xfrm-<ifname> to become free. Usage count = -381
> 
> This leads to a complete drop of our VPN links after some hours, and
> stalls the reboot for a couple of minutes waiting for devices to become
> free (I remember waiting 10-15 minutes for the shutdown when remote
> rebooting a gateway without physical access)
> 
> known affected: 6.12.96 and 6.12.96, known unaffected 6.12.90
> Fixed in 7.1.5 via 63a300151999.

It does not apply cleanly to those trees, please provide a working
backport that you have tested and we will be glad to apply it.

thanks,

greg k-h

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

[Greg KH]

On Fri, Aug 07, 2026 at 04:21:55PM +0200, Matthias Merz wrote:
> Hello,
> 
> Please apply upstream commit 8045c0df98d4 ("xfrm: Fix dev use-after-free
> in xfrm async resumption") also to 6.12.y. Stable 7.1.5 contains this in
> 63a300151999.
> 
> It fixes 1c428b038400 ("xfrm: hold dev ref until after transport_finish
> NF_HOOK"), which is present in 6.12.y since 6.12.94. On our IPsec
> gateways using xfrm interfaces this issue underflows the interface
> refcount and hangs unregister_netdevice() on tunnel teardown, rekey or
> system shutdown:
> 
>   unregister_netdevice: waiting for xfrm-<ifname> to become free. Usage count = -381
> 
> This leads to a complete drop of our VPN links after some hours, and
> stalls the reboot for a couple of minutes waiting for devices to become
> free (I remember waiting 10-15 minutes for the shutdown when remote
> rebooting a gateway without physical access)
> 
> known affected: 6.12.96 and 6.12.96, known unaffected 6.12.90
> Fixed in 7.1.5 via 63a300151999.
> 
> Maybe you could also consider having a look at the other longterm
> releases, but I have no insight where it might apply.

Please provide a working version of the backport for 6.12.y and 6.18.y
and we will be glad to apply it as it does not apply cleanly as-is.

thanks,
greg k-h

[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