CVE-2025-37959 Affecting kernel-rt-debug-modules-internal package, versions *

Note: Versions mentioned in the description apply only to the upstream kernel-rt-debug-modules-internal package and not the kernel-rt-debug-modules-internal package as distributed by RHEL. See How to fix? for RHEL:8 relevant fixed versions and status.

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 isn't 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 host's XFRM layer to the container's XFRM layer where it's 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 container's 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 container's netns, __xfrm_policy_check drops the packet with LINUX_MIB_XFRMINNOPOLS because a (container-side) XFRM policy can't 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.

• https://access.redhat.com/security/cve/CVE-2025-37959
• 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