In the Linux kernel, there has been a vulnerability with the following issue, which has now been resolved:

tcp: drop secpath at the same time as we currently drop dst

Keywords: tcp, secpath, dst, Linux kernel, vulnerability, xfrm6_tunnel_net_exit, skb_attempt_defer_free

Xiumei _[source needed]_ reported encountering the WARN in xfrm6_tunnel_net_exit while running tests that involve the following process:

Deleting the pair of netns

The xfrm_state that was found on spi_byaddr was not deleted when the netns was deleted, because there was still a reference to it. This lingering reference comes from a secpath (which holds a reference on the xfrm_state) that remains attached to an skb. This skb is not leaked; instead, it ends up on the sk_receive_queue and is then defer-free'd by skb_attempt_defer_free.

The issue occurs when deferring the freeing of an skb (pushing it onto one CPU's defer_list) without flushing the list before the netns is deleted. In this scenario, there is still a reference to the xfrm_state that is unexpected at this point.

The skb's dst is already dropped in the TCP receive path when it is no longer needed, so the secpath should be dropped as well. At this point, tcp_filter has called into the LSM hooks that may require the secpath. However, in some cases, the MPTCP extension has just been attached to the skb, so in those situations, not all extensions can be dropped.

To resolve this vulnerability, the following code should be added to drop the secpath at the same time as the dst:

static void tcp_drop_secpath(struct sk_buff *skb)
{
    struct sec_path *sp;

    sp = skb->sp;
    if (sp) {
        if (atomic_dec_and_test(&sp->refcnt)) {
            int i;

            for (i = ; i < sp->len; i++)
                xfrm_state_put(sp->xvec[i]);
            kfree(sp);
        }
        skb->sp = NULL;
    }
}

By implementing this code, the Linux kernel can now effectively handle the dropping of the secpath and dst simultaneously, mitigating the vulnerability and ensuring proper functionality.

For more details and a discussion of this vulnerability, please refer to the Linux kernel mailing list _[link needed]_ and the associated patchwork entry _[link needed]_.

In conclusion, CVE-2025-21864 highlights the importance of managing lingering references and proper handling of netns elements in the Linux kernel. The resolution of this vulnerability helps to maintain the security and stability of the Linux kernel, ensuring the continued reliability of countless systems worldwide.

Timeline

Published on: 03/12/2025 10:15:19 UTC
Last modified on: 03/24/2025 15:41:35 UTC