CVE-2025-37959

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Scrub packet on bpf_redirect_peer<br /> <br /> When bpf_redirect_peer is used to redirect packets to a device in<br /> another network namespace, the skb isn&amp;#39;t scrubbed. That can lead skb<br /> information from one namespace to be "misused" in another namespace.<br /> <br /> As one example, this is causing Cilium to drop traffic when using<br /> bpf_redirect_peer to redirect packets that just went through IPsec<br /> decryption to a container namespace. The following pwru trace shows (1)<br /> the packet path from the host&amp;#39;s XFRM layer to the container&amp;#39;s XFRM<br /> layer where it&amp;#39;s dropped and (2) the number of active skb extensions at<br /> each function.<br /> <br /> NETNS MARK IFACE TUPLE FUNC<br /> 4026533547 d00 eth0 10.244.3.124:35473-&gt;10.244.2.158:53 xfrm_rcv_cb<br /> .active_extensions = (__u8)2,<br /> 4026533547 d00 eth0 10.244.3.124:35473-&gt;10.244.2.158:53 xfrm4_rcv_cb<br /> .active_extensions = (__u8)2,<br /> 4026533547 d00 eth0 10.244.3.124:35473-&gt;10.244.2.158:53 gro_cells_receive<br /> .active_extensions = (__u8)2,<br /> [...]<br /> 4026533547 0 eth0 10.244.3.124:35473-&gt;10.244.2.158:53 skb_do_redirect<br /> .active_extensions = (__u8)2,<br /> 4026534999 0 eth0 10.244.3.124:35473-&gt;10.244.2.158:53 ip_rcv<br /> .active_extensions = (__u8)2,<br /> 4026534999 0 eth0 10.244.3.124:35473-&gt;10.244.2.158:53 ip_rcv_core<br /> .active_extensions = (__u8)2,<br /> [...]<br /> 4026534999 0 eth0 10.244.3.124:35473-&gt;10.244.2.158:53 udp_queue_rcv_one_skb<br /> .active_extensions = (__u8)2,<br /> 4026534999 0 eth0 10.244.3.124:35473-&gt;10.244.2.158:53 __xfrm_policy_check<br /> .active_extensions = (__u8)2,<br /> 4026534999 0 eth0 10.244.3.124:35473-&gt;10.244.2.158:53 __xfrm_decode_session<br /> .active_extensions = (__u8)2,<br /> 4026534999 0 eth0 10.244.3.124:35473-&gt;10.244.2.158:53 security_xfrm_decode_session<br /> .active_extensions = (__u8)2,<br /> 4026534999 0 eth0 10.244.3.124:35473-&gt;10.244.2.158:53 kfree_skb_reason(SKB_DROP_REASON_XFRM_POLICY)<br /> .active_extensions = (__u8)2,<br /> <br /> In this case, there are no XFRM policies in the container&amp;#39;s network<br /> namespace so the drop is unexpected. When we decrypt the IPsec packet,<br /> the XFRM state used for decryption is set in the skb extensions. This<br /> information is preserved across the netns switch. When we reach the<br /> XFRM policy check in the container&amp;#39;s netns, __xfrm_policy_check drops<br /> the packet with LINUX_MIB_XFRMINNOPOLS because a (container-side) XFRM<br /> policy can&amp;#39;t be found that matches the (host-side) XFRM state used for<br /> decryption.<br /> <br /> This patch fixes this by scrubbing the packet when using<br /> bpf_redirect_peer, as is done on typical netns switches via veth<br /> devices except skb-&gt;mark and skb-&gt;tstamp are not zeroed.