| From bippy-1.2.0 Mon Sep 17 00:00:00 2001 |
| From: Greg Kroah-Hartman <gregkh@kernel.org> |
| To: <linux-cve-announce@vger.kernel.org> |
| Reply-to: <cve@kernel.org>, <linux-kernel@vger.kernel.org> |
| Subject: CVE-2025-37959: bpf: Scrub packet on bpf_redirect_peer |
| |
| Description |
| =========== |
| |
| 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. |
| |
| The Linux kernel CVE team has assigned CVE-2025-37959 to this issue. |
| |
| |
| Affected and fixed versions |
| =========================== |
| |
| Issue introduced in 5.10 with commit 9aa1206e8f48222f35a0c809f33b2f4aaa1e2661 and fixed in 6.1.139 with commit de1067cc8cf0e8c11ae20cbe5c467aef19d04ded |
| Issue introduced in 5.10 with commit 9aa1206e8f48222f35a0c809f33b2f4aaa1e2661 and fixed in 6.6.91 with commit 355b0526336c0bf2bf7feaca033568ede524f763 |
| Issue introduced in 5.10 with commit 9aa1206e8f48222f35a0c809f33b2f4aaa1e2661 and fixed in 6.12.29 with commit b37e54259cab4f78b53953d6f6268b85f07bef3e |
| Issue introduced in 5.10 with commit 9aa1206e8f48222f35a0c809f33b2f4aaa1e2661 and fixed in 6.14.7 with commit 9e15ef33ba39fb6d9d1f51445957f16983a9437a |
| Issue introduced in 5.10 with commit 9aa1206e8f48222f35a0c809f33b2f4aaa1e2661 and fixed in 6.15 with commit c4327229948879814229b46aa26a750718888503 |
| |
| Please see https://www.kernel.org for a full list of currently supported |
| kernel versions by the kernel community. |
| |
| Unaffected versions might change over time as fixes are backported to |
| older supported kernel versions. The official CVE entry at |
| https://cve.org/CVERecord/?id=CVE-2025-37959 |
| will be updated if fixes are backported, please check that for the most |
| up to date information about this issue. |
| |
| |
| Affected files |
| ============== |
| |
| The file(s) affected by this issue are: |
| net/core/filter.c |
| |
| |
| Mitigation |
| ========== |
| |
| The Linux kernel CVE team recommends that you update to the latest |
| stable kernel version for this, and many other bugfixes. Individual |
| changes are never tested alone, but rather are part of a larger kernel |
| release. Cherry-picking individual commits is not recommended or |
| supported by the Linux kernel community at all. If however, updating to |
| the latest release is impossible, the individual changes to resolve this |
| issue can be found at these commits: |
| https://git.kernel.org/stable/c/de1067cc8cf0e8c11ae20cbe5c467aef19d04ded |
| https://git.kernel.org/stable/c/355b0526336c0bf2bf7feaca033568ede524f763 |
| https://git.kernel.org/stable/c/b37e54259cab4f78b53953d6f6268b85f07bef3e |
| https://git.kernel.org/stable/c/9e15ef33ba39fb6d9d1f51445957f16983a9437a |
| https://git.kernel.org/stable/c/c4327229948879814229b46aa26a750718888503 |
