{"api_version":"1","generated_at":"2026-07-23T14:13:40+00:00","cve":"CVE-2025-37959","urls":{"html":"https://cve.report/CVE-2025-37959","api":"https://cve.report/api/cve/CVE-2025-37959.json","docs":"https://cve.report/api","cve_org":"https://www.cve.org/CVERecord?id=CVE-2025-37959","nvd":"https://nvd.nist.gov/vuln/detail/CVE-2025-37959"},"summary":{"title":"bpf: Scrub packet on bpf_redirect_peer","description":"In the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Scrub packet on bpf_redirect_peer\n\nWhen bpf_redirect_peer is used to redirect packets to a device in\nanother network namespace, the skb isn't scrubbed. That can lead skb\ninformation from one namespace to be \"misused\" in another namespace.\n\nAs one example, this is causing Cilium to drop traffic when using\nbpf_redirect_peer to redirect packets that just went through IPsec\ndecryption to a container namespace. The following pwru trace shows (1)\nthe packet path from the host's XFRM layer to the container's XFRM\nlayer where it's dropped and (2) the number of active skb extensions at\neach function.\n\n    NETNS       MARK  IFACE  TUPLE                                FUNC\n    4026533547  d00   eth0   10.244.3.124:35473->10.244.2.158:53  xfrm_rcv_cb\n                             .active_extensions = (__u8)2,\n    4026533547  d00   eth0   10.244.3.124:35473->10.244.2.158:53  xfrm4_rcv_cb\n                             .active_extensions = (__u8)2,\n    4026533547  d00   eth0   10.244.3.124:35473->10.244.2.158:53  gro_cells_receive\n                             .active_extensions = (__u8)2,\n    [...]\n    4026533547  0     eth0   10.244.3.124:35473->10.244.2.158:53  skb_do_redirect\n                             .active_extensions = (__u8)2,\n    4026534999  0     eth0   10.244.3.124:35473->10.244.2.158:53  ip_rcv\n                             .active_extensions = (__u8)2,\n    4026534999  0     eth0   10.244.3.124:35473->10.244.2.158:53  ip_rcv_core\n                             .active_extensions = (__u8)2,\n    [...]\n    4026534999  0     eth0   10.244.3.124:35473->10.244.2.158:53  udp_queue_rcv_one_skb\n                             .active_extensions = (__u8)2,\n    4026534999  0     eth0   10.244.3.124:35473->10.244.2.158:53  __xfrm_policy_check\n                             .active_extensions = (__u8)2,\n    4026534999  0     eth0   10.244.3.124:35473->10.244.2.158:53  __xfrm_decode_session\n                             .active_extensions = (__u8)2,\n    4026534999  0     eth0   10.244.3.124:35473->10.244.2.158:53  security_xfrm_decode_session\n                             .active_extensions = (__u8)2,\n    4026534999  0     eth0   10.244.3.124:35473->10.244.2.158:53  kfree_skb_reason(SKB_DROP_REASON_XFRM_POLICY)\n                             .active_extensions = (__u8)2,\n\nIn this case, there are no XFRM policies in the container's network\nnamespace so the drop is unexpected. When we decrypt the IPsec packet,\nthe XFRM state used for decryption is set in the skb extensions. This\ninformation is preserved across the netns switch. When we reach the\nXFRM policy check in the container's netns, __xfrm_policy_check drops\nthe packet with LINUX_MIB_XFRMINNOPOLS because a (container-side) XFRM\npolicy can't be found that matches the (host-side) XFRM state used for\ndecryption.\n\nThis patch fixes this by scrubbing the packet when using\nbpf_redirect_peer, as is done on typical netns switches via veth\ndevices except skb->mark and skb->tstamp are not zeroed.","state":"PUBLISHED","assigner":"Linux","published_at":"2025-05-20 16:15:34","updated_at":"2026-07-14 13:17:34"},"problem_types":["NVD-CWE-noinfo"],"metrics":[{"version":"3.1","source":"nvd@nist.gov","type":"Primary","score":"5.5","severity":"MEDIUM","vector":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H","data":{"version":"3.1","vectorString":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H","baseScore":5.5,"baseSeverity":"MEDIUM","attackVector":"LOCAL","attackComplexity":"LOW","privilegesRequired":"LOW","userInteraction":"NONE","scope":"UNCHANGED","confidentialityImpact":"NONE","integrityImpact":"NONE","availabilityImpact":"HIGH"}}],"references":[{"url":"https://git.kernel.org/stable/c/b37e54259cab4f78b53953d6f6268b85f07bef3e","name":"https://git.kernel.org/stable/c/b37e54259cab4f78b53953d6f6268b85f07bef3e","refsource":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":["Patch"],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://lists.debian.org/debian-lts-announce/2025/08/msg00010.html","name":"https://lists.debian.org/debian-lts-announce/2025/08/msg00010.html","refsource":"af854a3a-2127-422b-91ae-364da2661108","tags":["Third Party Advisory"],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://cert-portal.siemens.com/productcert/html/ssa-019113.html","name":"https://cert-portal.siemens.com/productcert/html/ssa-019113.html","refsource":"0b142b55-0307-4c5a-b3c9-f314f3fb7c5e","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://git.kernel.org/stable/c/de1067cc8cf0e8c11ae20cbe5c467aef19d04ded","name":"https://git.kernel.org/stable/c/de1067cc8cf0e8c11ae20cbe5c467aef19d04ded","refsource":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":["Patch"],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://git.kernel.org/stable/c/355b0526336c0bf2bf7feaca033568ede524f763","name":"https://git.kernel.org/stable/c/355b0526336c0bf2bf7feaca033568ede524f763","refsource":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":["Patch"],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://git.kernel.org/stable/c/c4327229948879814229b46aa26a750718888503","name":"https://git.kernel.org/stable/c/c4327229948879814229b46aa26a750718888503","refsource":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":["Patch"],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://git.kernel.org/stable/c/9e15ef33ba39fb6d9d1f51445957f16983a9437a","name":"https://git.kernel.org/stable/c/9e15ef33ba39fb6d9d1f51445957f16983a9437a","refsource":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":["Patch"],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://www.cve.org/CVERecord?id=CVE-2025-37959","name":"CVE Program record","refsource":"CVE.ORG","tags":["canonical"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2025-37959","name":"NVD vulnerability detail","refsource":"NVD","tags":["canonical","analysis"]}],"affected":[{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected 9aa1206e8f48222f35a0c809f33b2f4aaa1e2661 de1067cc8cf0e8c11ae20cbe5c467aef19d04ded git","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected 9aa1206e8f48222f35a0c809f33b2f4aaa1e2661 355b0526336c0bf2bf7feaca033568ede524f763 git","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected 9aa1206e8f48222f35a0c809f33b2f4aaa1e2661 b37e54259cab4f78b53953d6f6268b85f07bef3e git","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected 9aa1206e8f48222f35a0c809f33b2f4aaa1e2661 9e15ef33ba39fb6d9d1f51445957f16983a9437a git","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected 9aa1206e8f48222f35a0c809f33b2f4aaa1e2661 c4327229948879814229b46aa26a750718888503 git","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected 5.10","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 5.10 semver","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 6.1.139 6.1.* semver","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 6.6.91 6.6.* semver","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 6.12.29 6.12.* semver","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 6.14.7 6.14.* semver","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 6.15 * original_commit_for_fix","platforms":[]},{"source":"ADP","vendor":"Siemens","product":"SIMATIC S7-1500 CPU 1518-4 PN/DP MFP","version":"affected V3.1.6 * custom","platforms":[]},{"source":"ADP","vendor":"Siemens","product":"SIMATIC S7-1500 CPU 1518-4 PN/DP MFP","version":"affected V3.1.6 * custom","platforms":[]},{"source":"ADP","vendor":"Siemens","product":"SIMATIC S7-1500 CPU 1518F-4 PN/DP MFP","version":"affected V3.1.6 * custom","platforms":[]},{"source":"ADP","vendor":"Siemens","product":"SIMATIC S7-1500 CPU 1518F-4 PN/DP MFP","version":"affected V3.1.6 * custom","platforms":[]},{"source":"ADP","vendor":"Siemens","product":"SIPLUS S7-1500 CPU 1518-4 PN/DP MFP","version":"affected V3.1.6 * custom","platforms":[]}],"timeline":[],"solutions":[],"workarounds":[],"exploits":[],"credits":[],"nvd_cpes":[{"cve_year":"2025","cve_id":"37959","vulnerable":"1","versionEndIncluding":"","cpe1":"cpe","cpe2":"2.3","cpe3":"o","cpe4":"linux","cpe5":"linux_kernel","cpe6":"*","cpe7":"*","cpe8":"*","cpe9":"*","cpe10":"*","cpe11":"*","cpe12":"*","cpe13":"*"}],"vendor_comments":[],"enrichments":{"kev":null,"epss":null,"legacy_qids":[]},"source_records":{"cve_program":{"containers":{"adp":[{"providerMetadata":{"dateUpdated":"2025-11-03T19:57:44.271Z","orgId":"af854a3a-2127-422b-91ae-364da2661108","shortName":"CVE"},"references":[{"url":"https://lists.debian.org/debian-lts-announce/2025/08/msg00010.html"}],"title":"CVE Program Container"},{"affected":[{"defaultStatus":"unknown","product":"SIMATIC S7-1500 CPU 1518-4 PN/DP MFP","vendor":"Siemens","versions":[{"lessThan":"*","status":"affected","version":"V3.1.6","versionType":"custom"}]},{"defaultStatus":"unknown","product":"SIMATIC S7-1500 CPU 1518-4 PN/DP MFP","vendor":"Siemens","versions":[{"lessThan":"*","status":"affected","version":"V3.1.6","versionType":"custom"}]},{"defaultStatus":"unknown","product":"SIMATIC S7-1500 CPU 1518F-4 PN/DP MFP","vendor":"Siemens","versions":[{"lessThan":"*","status":"affected","version":"V3.1.6","versionType":"custom"}]},{"defaultStatus":"unknown","product":"SIMATIC S7-1500 CPU 1518F-4 PN/DP MFP","vendor":"Siemens","versions":[{"lessThan":"*","status":"affected","version":"V3.1.6","versionType":"custom"}]},{"defaultStatus":"unknown","product":"SIPLUS S7-1500 CPU 1518-4 PN/DP MFP","vendor":"Siemens","versions":[{"lessThan":"*","status":"affected","version":"V3.1.6","versionType":"custom"}]}],"providerMetadata":{"dateUpdated":"2026-07-14T12:41:15.298Z","orgId":"0b142b55-0307-4c5a-b3c9-f314f3fb7c5e","shortName":"siemens-SADP"},"references":[{"url":"https://cert-portal.siemens.com/productcert/html/ssa-019113.html"}],"x_adpType":"supplier"}],"cna":{"affected":[{"defaultStatus":"unaffected","product":"Linux","programFiles":["net/core/filter.c"],"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","versions":[{"lessThan":"de1067cc8cf0e8c11ae20cbe5c467aef19d04ded","status":"affected","version":"9aa1206e8f48222f35a0c809f33b2f4aaa1e2661","versionType":"git"},{"lessThan":"355b0526336c0bf2bf7feaca033568ede524f763","status":"affected","version":"9aa1206e8f48222f35a0c809f33b2f4aaa1e2661","versionType":"git"},{"lessThan":"b37e54259cab4f78b53953d6f6268b85f07bef3e","status":"affected","version":"9aa1206e8f48222f35a0c809f33b2f4aaa1e2661","versionType":"git"},{"lessThan":"9e15ef33ba39fb6d9d1f51445957f16983a9437a","status":"affected","version":"9aa1206e8f48222f35a0c809f33b2f4aaa1e2661","versionType":"git"},{"lessThan":"c4327229948879814229b46aa26a750718888503","status":"affected","version":"9aa1206e8f48222f35a0c809f33b2f4aaa1e2661","versionType":"git"}]},{"defaultStatus":"affected","product":"Linux","programFiles":["net/core/filter.c"],"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","versions":[{"status":"affected","version":"5.10"},{"lessThan":"5.10","status":"unaffected","version":"0","versionType":"semver"},{"lessThanOrEqual":"6.1.*","status":"unaffected","version":"6.1.139","versionType":"semver"},{"lessThanOrEqual":"6.6.*","status":"unaffected","version":"6.6.91","versionType":"semver"},{"lessThanOrEqual":"6.12.*","status":"unaffected","version":"6.12.29","versionType":"semver"},{"lessThanOrEqual":"6.14.*","status":"unaffected","version":"6.14.7","versionType":"semver"},{"lessThanOrEqual":"*","status":"unaffected","version":"6.15","versionType":"original_commit_for_fix"}]}],"cpeApplicability":[{"nodes":[{"cpeMatch":[{"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionEndExcluding":"6.1.139","versionStartIncluding":"5.10","vulnerable":true},{"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionEndExcluding":"6.6.91","versionStartIncluding":"5.10","vulnerable":true},{"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionEndExcluding":"6.12.29","versionStartIncluding":"5.10","vulnerable":true},{"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionEndExcluding":"6.14.7","versionStartIncluding":"5.10","vulnerable":true},{"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionEndExcluding":"6.15","versionStartIncluding":"5.10","vulnerable":true}],"negate":false,"operator":"OR"}]}],"descriptions":[{"lang":"en","value":"In the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Scrub packet on bpf_redirect_peer\n\nWhen bpf_redirect_peer is used to redirect packets to a device in\nanother network namespace, the skb isn't scrubbed. That can lead skb\ninformation from one namespace to be \"misused\" in another namespace.\n\nAs one example, this is causing Cilium to drop traffic when using\nbpf_redirect_peer to redirect packets that just went through IPsec\ndecryption to a container namespace. The following pwru trace shows (1)\nthe packet path from the host's XFRM layer to the container's XFRM\nlayer where it's dropped and (2) the number of active skb extensions at\neach function.\n\n    NETNS       MARK  IFACE  TUPLE                                FUNC\n    4026533547  d00   eth0   10.244.3.124:35473->10.244.2.158:53  xfrm_rcv_cb\n                             .active_extensions = (__u8)2,\n    4026533547  d00   eth0   10.244.3.124:35473->10.244.2.158:53  xfrm4_rcv_cb\n                             .active_extensions = (__u8)2,\n    4026533547  d00   eth0   10.244.3.124:35473->10.244.2.158:53  gro_cells_receive\n                             .active_extensions = (__u8)2,\n    [...]\n    4026533547  0     eth0   10.244.3.124:35473->10.244.2.158:53  skb_do_redirect\n                             .active_extensions = (__u8)2,\n    4026534999  0     eth0   10.244.3.124:35473->10.244.2.158:53  ip_rcv\n                             .active_extensions = (__u8)2,\n    4026534999  0     eth0   10.244.3.124:35473->10.244.2.158:53  ip_rcv_core\n                             .active_extensions = (__u8)2,\n    [...]\n    4026534999  0     eth0   10.244.3.124:35473->10.244.2.158:53  udp_queue_rcv_one_skb\n                             .active_extensions = (__u8)2,\n    4026534999  0     eth0   10.244.3.124:35473->10.244.2.158:53  __xfrm_policy_check\n                             .active_extensions = (__u8)2,\n    4026534999  0     eth0   10.244.3.124:35473->10.244.2.158:53  __xfrm_decode_session\n                             .active_extensions = (__u8)2,\n    4026534999  0     eth0   10.244.3.124:35473->10.244.2.158:53  security_xfrm_decode_session\n                             .active_extensions = (__u8)2,\n    4026534999  0     eth0   10.244.3.124:35473->10.244.2.158:53  kfree_skb_reason(SKB_DROP_REASON_XFRM_POLICY)\n                             .active_extensions = (__u8)2,\n\nIn this case, there are no XFRM policies in the container's network\nnamespace so the drop is unexpected. When we decrypt the IPsec packet,\nthe XFRM state used for decryption is set in the skb extensions. This\ninformation is preserved across the netns switch. When we reach the\nXFRM policy check in the container's netns, __xfrm_policy_check drops\nthe packet with LINUX_MIB_XFRMINNOPOLS because a (container-side) XFRM\npolicy can't be found that matches the (host-side) XFRM state used for\ndecryption.\n\nThis patch fixes this by scrubbing the packet when using\nbpf_redirect_peer, as is done on typical netns switches via veth\ndevices except skb->mark and skb->tstamp are not zeroed."}],"providerMetadata":{"dateUpdated":"2026-05-11T21:18:24.762Z","orgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","shortName":"Linux"},"references":[{"url":"https://git.kernel.org/stable/c/de1067cc8cf0e8c11ae20cbe5c467aef19d04ded"},{"url":"https://git.kernel.org/stable/c/355b0526336c0bf2bf7feaca033568ede524f763"},{"url":"https://git.kernel.org/stable/c/b37e54259cab4f78b53953d6f6268b85f07bef3e"},{"url":"https://git.kernel.org/stable/c/9e15ef33ba39fb6d9d1f51445957f16983a9437a"},{"url":"https://git.kernel.org/stable/c/c4327229948879814229b46aa26a750718888503"}],"title":"bpf: Scrub packet on bpf_redirect_peer","x_generator":{"engine":"bippy-1.2.0"}}},"cveMetadata":{"assignerOrgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","assignerShortName":"Linux","cveId":"CVE-2025-37959","datePublished":"2025-05-20T16:01:52.547Z","dateReserved":"2025-04-16T04:51:23.974Z","dateUpdated":"2026-07-14T12:41:15.298Z","state":"PUBLISHED"},"dataType":"CVE_RECORD","dataVersion":"5.2"},"nvd":{"publishedDate":"2025-05-20 16:15:34","lastModifiedDate":"2026-07-14 13:17:34","problem_types":["NVD-CWE-noinfo"],"metrics":{"cvssMetricV31":[{"source":"nvd@nist.gov","type":"Primary","cvssData":{"version":"3.1","vectorString":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H","baseScore":5.5,"baseSeverity":"MEDIUM","attackVector":"LOCAL","attackComplexity":"LOW","privilegesRequired":"LOW","userInteraction":"NONE","scope":"UNCHANGED","confidentialityImpact":"NONE","integrityImpact":"NONE","availabilityImpact":"HIGH"},"exploitabilityScore":1.8,"impactScore":3.6}]},"configurations":[{"nodes":[{"operator":"OR","negate":false,"cpeMatch":[{"vulnerable":true,"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionStartIncluding":"5.10","versionEndExcluding":"6.1.139","matchCriteriaId":"6344D77A-F28F-4267-8F00-80DA1C760CA7"},{"vulnerable":true,"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionStartIncluding":"6.2","versionEndExcluding":"6.6.91","matchCriteriaId":"B6826C73-C5C9-430D-84C9-4045DFD72074"},{"vulnerable":true,"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionStartIncluding":"6.7","versionEndExcluding":"6.12.29","matchCriteriaId":"7215ABCF-8EB1-46CD-8872-8BCE4890E579"},{"vulnerable":true,"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionStartIncluding":"6.13","versionEndExcluding":"6.14.7","matchCriteriaId":"5715A6F5-A34A-4B27-8A64-82825E963995"},{"vulnerable":true,"criteria":"cpe:2.3:o:linux:linux_kernel:6.15:rc1:*:*:*:*:*:*","matchCriteriaId":"8D465631-2980-487A-8E65-40AE2B9F8ED1"},{"vulnerable":true,"criteria":"cpe:2.3:o:linux:linux_kernel:6.15:rc2:*:*:*:*:*:*","matchCriteriaId":"4C9D071F-B28E-46EC-AC61-22B913390211"},{"vulnerable":true,"criteria":"cpe:2.3:o:linux:linux_kernel:6.15:rc3:*:*:*:*:*:*","matchCriteriaId":"13FC0DDE-E513-465E-9E81-515702D49B74"},{"vulnerable":true,"criteria":"cpe:2.3:o:linux:linux_kernel:6.15:rc4:*:*:*:*:*:*","matchCriteriaId":"8C7B5B0E-4EEB-48F5-B4CF-0935A7633845"},{"vulnerable":true,"criteria":"cpe:2.3:o:linux:linux_kernel:6.15:rc5:*:*:*:*:*:*","matchCriteriaId":"2D240580-3048-49B2-9E27-F115A9DF8224"}]}]},{"nodes":[{"operator":"OR","negate":false,"cpeMatch":[{"vulnerable":true,"criteria":"cpe:2.3:o:debian:debian_linux:11.0:*:*:*:*:*:*:*","matchCriteriaId":"FA6FEEC2-9F11-4643-8827-749718254FED"}]}]}]},"legacy_mitre":{"record":{"CveYear":"2025","CveId":"37959","Ordinal":"1","Title":"bpf: Scrub packet on bpf_redirect_peer","CVE":"CVE-2025-37959","Year":"2025"},"notes":[{"CveYear":"2025","CveId":"37959","Ordinal":"1","NoteData":"In the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Scrub packet on bpf_redirect_peer\n\nWhen bpf_redirect_peer is used to redirect packets to a device in\nanother network namespace, the skb isn't scrubbed. That can lead skb\ninformation from one namespace to be \"misused\" in another namespace.\n\nAs one example, this is causing Cilium to drop traffic when using\nbpf_redirect_peer to redirect packets that just went through IPsec\ndecryption to a container namespace. The following pwru trace shows (1)\nthe packet path from the host's XFRM layer to the container's XFRM\nlayer where it's dropped and (2) the number of active skb extensions at\neach function.\n\n    NETNS       MARK  IFACE  TUPLE                                FUNC\n    4026533547  d00   eth0   10.244.3.124:35473->10.244.2.158:53  xfrm_rcv_cb\n                             .active_extensions = (__u8)2,\n    4026533547  d00   eth0   10.244.3.124:35473->10.244.2.158:53  xfrm4_rcv_cb\n                             .active_extensions = (__u8)2,\n    4026533547  d00   eth0   10.244.3.124:35473->10.244.2.158:53  gro_cells_receive\n                             .active_extensions = (__u8)2,\n    [...]\n    4026533547  0     eth0   10.244.3.124:35473->10.244.2.158:53  skb_do_redirect\n                             .active_extensions = (__u8)2,\n    4026534999  0     eth0   10.244.3.124:35473->10.244.2.158:53  ip_rcv\n                             .active_extensions = (__u8)2,\n    4026534999  0     eth0   10.244.3.124:35473->10.244.2.158:53  ip_rcv_core\n                             .active_extensions = (__u8)2,\n    [...]\n    4026534999  0     eth0   10.244.3.124:35473->10.244.2.158:53  udp_queue_rcv_one_skb\n                             .active_extensions = (__u8)2,\n    4026534999  0     eth0   10.244.3.124:35473->10.244.2.158:53  __xfrm_policy_check\n                             .active_extensions = (__u8)2,\n    4026534999  0     eth0   10.244.3.124:35473->10.244.2.158:53  __xfrm_decode_session\n                             .active_extensions = (__u8)2,\n    4026534999  0     eth0   10.244.3.124:35473->10.244.2.158:53  security_xfrm_decode_session\n                             .active_extensions = (__u8)2,\n    4026534999  0     eth0   10.244.3.124:35473->10.244.2.158:53  kfree_skb_reason(SKB_DROP_REASON_XFRM_POLICY)\n                             .active_extensions = (__u8)2,\n\nIn this case, there are no XFRM policies in the container's network\nnamespace so the drop is unexpected. When we decrypt the IPsec packet,\nthe XFRM state used for decryption is set in the skb extensions. This\ninformation is preserved across the netns switch. When we reach the\nXFRM policy check in the container's netns, __xfrm_policy_check drops\nthe packet with LINUX_MIB_XFRMINNOPOLS because a (container-side) XFRM\npolicy can't be found that matches the (host-side) XFRM state used for\ndecryption.\n\nThis patch fixes this by scrubbing the packet when using\nbpf_redirect_peer, as is done on typical netns switches via veth\ndevices except skb->mark and skb->tstamp are not zeroed.","Type":"Description","Title":"bpf: Scrub packet on bpf_redirect_peer"}]}}}