CVE-2025-37959
Publication date:
20/05/2025
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&#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&#39;s XFRM layer to the container&#39;s XFRM<br />
layer where it&#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->10.244.2.158:53 xfrm_rcv_cb<br />
.active_extensions = (__u8)2,<br />
4026533547 d00 eth0 10.244.3.124:35473->10.244.2.158:53 xfrm4_rcv_cb<br />
.active_extensions = (__u8)2,<br />
4026533547 d00 eth0 10.244.3.124:35473->10.244.2.158:53 gro_cells_receive<br />
.active_extensions = (__u8)2,<br />
[...]<br />
4026533547 0 eth0 10.244.3.124:35473->10.244.2.158:53 skb_do_redirect<br />
.active_extensions = (__u8)2,<br />
4026534999 0 eth0 10.244.3.124:35473->10.244.2.158:53 ip_rcv<br />
.active_extensions = (__u8)2,<br />
4026534999 0 eth0 10.244.3.124:35473->10.244.2.158:53 ip_rcv_core<br />
.active_extensions = (__u8)2,<br />
[...]<br />
4026534999 0 eth0 10.244.3.124:35473->10.244.2.158:53 udp_queue_rcv_one_skb<br />
.active_extensions = (__u8)2,<br />
4026534999 0 eth0 10.244.3.124:35473->10.244.2.158:53 __xfrm_policy_check<br />
.active_extensions = (__u8)2,<br />
4026534999 0 eth0 10.244.3.124:35473->10.244.2.158:53 __xfrm_decode_session<br />
.active_extensions = (__u8)2,<br />
4026534999 0 eth0 10.244.3.124:35473->10.244.2.158:53 security_xfrm_decode_session<br />
.active_extensions = (__u8)2,<br />
4026534999 0 eth0 10.244.3.124:35473->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&#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&#39;s netns, __xfrm_policy_check drops<br />
the packet with LINUX_MIB_XFRMINNOPOLS because a (container-side) XFRM<br />
policy can&#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->mark and skb->tstamp are not zeroed.
Severity CVSS v4.0: Pending analysis
Last modification:
21/05/2025