CVE-2025-40215

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xfrm: delete x-&gt;tunnel as we delete x<br /> <br /> The ipcomp fallback tunnels currently get deleted (from the various<br /> lists and hashtables) as the last user state that needed that fallback<br /> is destroyed (not deleted). If a reference to that user state still<br /> exists, the fallback state will remain on the hashtables/lists,<br /> triggering the WARN in xfrm_state_fini. Because of those remaining<br /> references, the fix in commit f75a2804da39 ("xfrm: destroy xfrm_state<br /> synchronously on net exit path") is not complete.<br /> <br /> We recently fixed one such situation in TCP due to defered freeing of<br /> skbs (commit 9b6412e6979f ("tcp: drop secpath at the same time as we<br /> currently drop dst")). This can also happen due to IP reassembly: skbs<br /> with a secpath remain on the reassembly queue until netns<br /> destruction. If we can&amp;#39;t guarantee that the queues are flushed by the<br /> time xfrm_state_fini runs, there may still be references to a (user)<br /> xfrm_state, preventing the timely deletion of the corresponding<br /> fallback state.<br /> <br /> Instead of chasing each instance of skbs holding a secpath one by one,<br /> this patch fixes the issue directly within xfrm, by deleting the<br /> fallback state as soon as the last user state depending on it has been<br /> deleted. Destruction will still happen when the final reference is<br /> dropped.<br /> <br /> A separate lockdep class for the fallback state is required since<br /> we&amp;#39;re going to lock x-&gt;tunnel while x is locked.