ghsa-g5rc-wjvg-94w5
Vulnerability from github
Published
2025-05-20 18:30
Modified
2025-05-20 18:30
Details

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.

Show details on source website

To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2025-37959"
  ],
  "database_specific": {
    "cwe_ids": [],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-05-20T16:15:34Z",
    "severity": null
  },
  "details": "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\u0027t 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\u0027s XFRM layer to the container\u0027s XFRM\nlayer where it\u0027s 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-\u003e10.244.2.158:53  xfrm_rcv_cb\n                             .active_extensions = (__u8)2,\n    4026533547  d00   eth0   10.244.3.124:35473-\u003e10.244.2.158:53  xfrm4_rcv_cb\n                             .active_extensions = (__u8)2,\n    4026533547  d00   eth0   10.244.3.124:35473-\u003e10.244.2.158:53  gro_cells_receive\n                             .active_extensions = (__u8)2,\n    [...]\n    4026533547  0     eth0   10.244.3.124:35473-\u003e10.244.2.158:53  skb_do_redirect\n                             .active_extensions = (__u8)2,\n    4026534999  0     eth0   10.244.3.124:35473-\u003e10.244.2.158:53  ip_rcv\n                             .active_extensions = (__u8)2,\n    4026534999  0     eth0   10.244.3.124:35473-\u003e10.244.2.158:53  ip_rcv_core\n                             .active_extensions = (__u8)2,\n    [...]\n    4026534999  0     eth0   10.244.3.124:35473-\u003e10.244.2.158:53  udp_queue_rcv_one_skb\n                             .active_extensions = (__u8)2,\n    4026534999  0     eth0   10.244.3.124:35473-\u003e10.244.2.158:53  __xfrm_policy_check\n                             .active_extensions = (__u8)2,\n    4026534999  0     eth0   10.244.3.124:35473-\u003e10.244.2.158:53  __xfrm_decode_session\n                             .active_extensions = (__u8)2,\n    4026534999  0     eth0   10.244.3.124:35473-\u003e10.244.2.158:53  security_xfrm_decode_session\n                             .active_extensions = (__u8)2,\n    4026534999  0     eth0   10.244.3.124:35473-\u003e10.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\u0027s 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\u0027s netns, __xfrm_policy_check drops\nthe packet with LINUX_MIB_XFRMINNOPOLS because a (container-side) XFRM\npolicy can\u0027t 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-\u003emark and skb-\u003etstamp are not zeroed.",
  "id": "GHSA-g5rc-wjvg-94w5",
  "modified": "2025-05-20T18:30:56Z",
  "published": "2025-05-20T18:30:56Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37959"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/355b0526336c0bf2bf7feaca033568ede524f763"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/9e15ef33ba39fb6d9d1f51445957f16983a9437a"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/b37e54259cab4f78b53953d6f6268b85f07bef3e"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/c4327229948879814229b46aa26a750718888503"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/de1067cc8cf0e8c11ae20cbe5c467aef19d04ded"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.




Sightings

Author Source Type Date

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
  • Confirmed: The vulnerability is confirmed from an analyst perspective.
  • Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
  • Patched: This vulnerability was successfully patched by the user reporting the sighting.
  • Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
  • Not confirmed: The user expresses doubt about the veracity of the vulnerability.
  • Not patched: This vulnerability was not successfully patched by the user reporting the sighting.