APPLIED: [SRU][J/N/Q][PATCH 0/2] CVE-2025-40215 and CVE-2025-40256

[Stefan Bader]

On 05/01/2026 23:43, Tim Whisonant wrote:
> SRU Justification:
> 
> [Impact]
> 
> xfrm: delete x->tunnel as we delete x
> 
> The ipcomp fallback tunnels currently get deleted (from the various
> lists and hashtables) as the last user state that needed that fallback
> is destroyed (not deleted). If a reference to that user state still
> exists, the fallback state will remain on the hashtables/lists,
> triggering the WARN in xfrm_state_fini. Because of those remaining
> references, the fix in commit f75a2804da39 ("xfrm: destroy xfrm_state
> synchronously on net exit path") is not complete.
> 
> We recently fixed one such situation in TCP due to defered freeing of
> skbs (commit 9b6412e6979f ("tcp: drop secpath at the same time as we
> currently drop dst")). This can also happen due to IP reassembly: skbs
> with a secpath remain on the reassembly queue until netns
> destruction. If we can't guarantee that the queues are flushed by the
> time xfrm_state_fini runs, there may still be references to a (user)
> xfrm_state, preventing the timely deletion of the corresponding
> fallback state.
> 
> Instead of chasing each instance of skbs holding a secpath one by one,
> this patch fixes the issue directly within xfrm, by deleting the
> fallback state as soon as the last user state depending on it has been
> deleted. Destruction will still happen when the final reference is
> dropped.
> 
> A separate lockdep class for the fallback state is required since
> we're going to lock x->tunnel while x is locked.
> 
> 
> xfrm: also call xfrm_state_delete_tunnel at destroy time for states that were never added
> 
> [ Upstream commit 10deb69864840ccf96b00ac2ab3a2055c0c04721 ]
> 
> In commit b441cf3f8c4b ("xfrm: delete x->tunnel as we delete x"), I
> missed the case where state creation fails between full
> initialization (->init_state has been called) and being inserted on
> the lists.
> 
> In this situation, ->init_state has been called, so for IPcomp
> tunnels, the fallback tunnel has been created and added onto the
> lists, but the user state never gets added, because we fail before
> that. The user state doesn't go through __xfrm_state_delete, so we
> don't call xfrm_state_delete_tunnel for those states, and we end up
> leaking the FB tunnel.
> 
> There are several codepaths affected by this: the add/update paths, in
> both net/key and xfrm, and the migrate code (xfrm_migrate,
> xfrm_state_migrate). A "proper" rollback of the init_state work would
> probably be doable in the add/update code, but for migrate it gets
> more complicated as multiple states may be involved.
> 
> At some point, the new (not-inserted) state will be destroyed, so call
> xfrm_state_delete_tunnel during xfrm_state_gc_destroy. Most states
> will have their fallback tunnel cleaned up during __xfrm_state_delete,
> which solves the issue that b441cf3f8c4b (and other patches before it)
> aimed at. All states (including FB tunnels) will be removed from the
> lists once xfrm_state_fini has called flush_work(&xfrm_state_gc_work).
> 
> [Fix]
> 
> Questing: cherry-picked from upstream (CVE-2025-40256 only)
> Noble:    applied Jammy patches
> Jammy:    backported from upstream
> Focal:    submitted to Forgejo
> Bionic:   submitted to esm ml
> Xenial:   submitted to esm ml
> Trusty:   out of scope (medium CVE)
> 
> [Test Plan]
> 
> Compile and boot tested.
> 
> [Where problems could occur]
> 
> The changes affect the core networking transform framework,
> specifically the ipcomp fallback tunnel state tracking.
> Issues might appear as problems cleaning up tunnel state.
> 
> [Notes]
> 
> For Questing, only CVE-2025-40256 is addressed as Questing already
> contained the fix for CVE-2025-40215.
> 
> Sabrina Dubroca (2):
>    xfrm: delete x->tunnel as we delete x
>    xfrm: also call xfrm_state_delete_tunnel at destroy time for states
>      that were never added
> 
>   include/net/xfrm.h      |  1 -
>   net/ipv4/ipcomp.c       |  2 ++
>   net/ipv6/ipcomp6.c      |  2 ++
>   net/ipv6/xfrm6_tunnel.c |  2 +-
>   net/xfrm/xfrm_ipcomp.c  |  1 -
>   net/xfrm/xfrm_state.c   | 20 +++++++++-----------
>   6 files changed, 14 insertions(+), 14 deletions(-)
> 


Applied to questing,noble,jammy:linux/master-next. Thanks.

-Stefan

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_0xE8675DEECBEECEA3.asc
Type: application/pgp-keys
Size: 48643 bytes
Desc: OpenPGP public key
URL: <https://lists.ubuntu.com/archives/kernel-team/attachments/20260108/39d7872b/attachment-0001.key>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ubuntu.com/archives/kernel-team/attachments/20260108/39d7872b/attachment-0001.sig>