CVE-2025-40256

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xfrm: also call xfrm_state_delete_tunnel at destroy time for states that were never added<br /> <br /> In commit b441cf3f8c4b ("xfrm: delete x-&gt;tunnel as we delete x"), I<br /> missed the case where state creation fails between full<br /> initialization (-&gt;init_state has been called) and being inserted on<br /> the lists.<br /> <br /> In this situation, -&gt;init_state has been called, so for IPcomp<br /> tunnels, the fallback tunnel has been created and added onto the<br /> lists, but the user state never gets added, because we fail before<br /> that. The user state doesn&amp;#39;t go through __xfrm_state_delete, so we<br /> don&amp;#39;t call xfrm_state_delete_tunnel for those states, and we end up<br /> leaking the FB tunnel.<br /> <br /> There are several codepaths affected by this: the add/update paths, in<br /> both net/key and xfrm, and the migrate code (xfrm_migrate,<br /> xfrm_state_migrate). A "proper" rollback of the init_state work would<br /> probably be doable in the add/update code, but for migrate it gets<br /> more complicated as multiple states may be involved.<br /> <br /> At some point, the new (not-inserted) state will be destroyed, so call<br /> xfrm_state_delete_tunnel during xfrm_state_gc_destroy. Most states<br /> will have their fallback tunnel cleaned up during __xfrm_state_delete,<br /> which solves the issue that b441cf3f8c4b (and other patches before it)<br /> aimed at. All states (including FB tunnels) will be removed from the<br /> lists once xfrm_state_fini has called flush_work(&amp;xfrm_state_gc_work).