CVE-2025-21864

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tcp: drop secpath at the same time as we currently drop dst<br /> <br /> Xiumei reported hitting the WARN in xfrm6_tunnel_net_exit while<br /> running tests that boil down to:<br /> - create a pair of netns<br /> - run a basic TCP test over ipcomp6<br /> - delete the pair of netns<br /> <br /> The xfrm_state found on spi_byaddr was not deleted at the time we<br /> delete the netns, because we still have a reference on it. This<br /> lingering reference comes from a secpath (which holds a ref on the<br /> xfrm_state), which is still attached to an skb. This skb is not<br /> leaked, it ends up on sk_receive_queue and then gets defer-free&amp;#39;d by<br /> skb_attempt_defer_free.<br /> <br /> The problem happens when we defer freeing an skb (push it on one CPU&amp;#39;s<br /> defer_list), and don&amp;#39;t flush that list before the netns is deleted. In<br /> that case, we still have a reference on the xfrm_state that we don&amp;#39;t<br /> expect at this point.<br /> <br /> We already drop the skb&amp;#39;s dst in the TCP receive path when it&amp;#39;s no<br /> longer needed, so let&amp;#39;s also drop the secpath. At this point,<br /> tcp_filter has already called into the LSM hooks that may require the<br /> secpath, so it should not be needed anymore. However, in some of those<br /> places, the MPTCP extension has just been attached to the skb, so we<br /> cannot simply drop all extensions.