CVE-2025-37959

In the Linux kernel, the following vulnerability has been resolved:

bpf: Scrub packet on bpf_redirect_peer

When bpf_redirect_peer is used to redirect packets to a device in another network namespace, the skb isnt scrubbed. That can lead skb information from one namespace to be misused in another namespace.

As one example, this is causing Cilium to drop traffic when using bpf_redirect_peer to redirect packets that just went through IPsec decryption to a container namespace. The following pwru trace shows (1) the packet path from the hosts XFRM layer to the containers XFRM layer where its dropped and (2) the number of active skb extensions at each function.

NETNS       MARK  IFACE  TUPLE                                FUNC
4026533547  d00   eth0   10.244.3.124:35473->10.244.2.158:53  xfrm_rcv_cb
                         .active_extensions = (__u8)2,
4026533547  d00   eth0   10.244.3.124:35473->10.244.2.158:53  xfrm4_rcv_cb
                         .active_extensions = (__u8)2,
4026533547  d00   eth0   10.244.3.124:35473->10.244.2.158:53  gro_cells_receive
                         .active_extensions = (__u8)2,
[...]
4026533547  0     eth0   10.244.3.124:35473->10.244.2.158:53  skb_do_redirect
                         .active_extensions = (__u8)2,
4026534999  0     eth0   10.244.3.124:35473->10.244.2.158:53  ip_rcv
                         .active_extensions = (__u8)2,
4026534999  0     eth0   10.244.3.124:35473->10.244.2.158:53  ip_rcv_core
                         .active_extensions = (__u8)2,
[...]
4026534999  0     eth0   10.244.3.124:35473->10.244.2.158:53  udp_queue_rcv_one_skb
                         .active_extensions = (__u8)2,
4026534999  0     eth0   10.244.3.124:35473->10.244.2.158:53  __xfrm_policy_check
                         .active_extensions = (__u8)2,
4026534999  0     eth0   10.244.3.124:35473->10.244.2.158:53  __xfrm_decode_session
                         .active_extensions = (__u8)2,
4026534999  0     eth0   10.244.3.124:35473->10.244.2.158:53  security_xfrm_decode_session
                         .active_extensions = (__u8)2,
4026534999  0     eth0   10.244.3.124:35473->10.244.2.158:53  kfree_skb_reason(SKB_DROP_REASON_XFRM_POLICY)
                         .active_extensions = (__u8)2,

In this case, there are no XFRM policies in the containers network namespace so the drop is unexpected. When we decrypt the IPsec packet, the XFRM state used for decryption is set in the skb extensions. This information is preserved across the netns switch. When we reach the XFRM policy check in the containers netns, __xfrm_policy_check drops the packet with LINUX_MIB_XFRMINNOPOLS because a (container-side) XFRM policy cant be found that matches the (host-side) XFRM state used for decryption.

This patch fixes this by scrubbing the packet when using bpf_redirect_peer, as is done on typical netns switches via veth devices except skb->mark and skb->tstamp are not zeroed.

Affected Software

References

• https://git.kernel.org/stable/c/355b0526336c0bf2bf7feaca033568ede524f763
• https://git.kernel.org/stable/c/9e15ef33ba39fb6d9d1f51445957f16983a9437a
• https://git.kernel.org/stable/c/b37e54259cab4f78b53953d6f6268b85f07bef3e
• https://git.kernel.org/stable/c/c4327229948879814229b46aa26a750718888503
• https://git.kernel.org/stable/c/de1067cc8cf0e8c11ae20cbe5c467aef19d04ded
• https://lists.debian.org/debian-lts-announce/2025/08/msg00010.html