CVE-2025-37959
What it is
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.
At a glance
- Exploitability
- Can be exploited over the network without logging in. High risk of data tampering, service disruption.
- Exploit odds
- 0.4% chance of exploitation in the next 30 days (EPSS).
- Fix
- A patch, advisory or fixed version is referenced. Upgrade or apply it.
Timeline
- PublishedDisclosed publicly on CVE.org and NVD
- Last updatedMost recent change to the record
Why it ranks here
- Exploited in the wild: no, CISA does not list it.
- Exploit odds: 0.4% in the next 30 days (EPSS).
- Severity: 9.4 CRITICAL (CVSS).
- Fix: a patch or advisory is linked.
Details
- Published
- Last modified
- Exploit probability
- 0.4% · EPSS, next 30 days
- Record status
- Modified
Affected
- Linux Kernel < 6.1.139
- Linux Kernel < 6.6.91
- Linux Kernel < 6.12.29
- Linux Kernel < 6.14.7
- Linux Kernel 6.15
- Debian Linux 11.0
Attack profile CVSS 3.1 · 9.4
- Attack vector
- Network
- Complexity
- Low
- Privileges needed
- None
- User interaction
- None
- Scope
- Unchanged
- Confidentiality
- Low
- Integrity
- High
- Availability
- High
Raw vector
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:H/A:H
Is it in your code?
Hand this to your coding agent. It searches your project for the affected products and checks versions. Nothing leaves your machine.
Read https://cve-list.com/agent/cve/CVE-2025-37959.md and follow it. Check whether this project is affected by CVE-2025-37959. Read only. Don't change anything and don't upload my code. Tell me yes, no or not sure, with the file as proof.
Fix and advisories
- 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
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
- https://cert-portal.siemens.com/productcert/html/ssa-019113.html
- https://cert-portal.siemens.com/productcert/html/ssa-457936.html