GHSA-75W2-9M25-JVQG

Vulnerability from github – Published: 2025-12-09 18:30 – Updated: 2025-12-09 18:30
VLAI?
Details

In the Linux kernel, the following vulnerability has been resolved:

i40e: Fix DMA mappings leak

During reallocation of RX buffers, new DMA mappings are created for those buffers.

steps for reproduction: while : do for ((i=0; i<=8160; i=i+32)) do ethtool -G enp130s0f0 rx $i tx $i sleep 0.5 ethtool -g enp130s0f0 done done

This resulted in crash: i40e 0000:01:00.1: Unable to allocate memory for the Rx descriptor ring, size=65536 Driver BUG WARNING: CPU: 0 PID: 4300 at net/core/xdp.c:141 xdp_rxq_info_unreg+0x43/0x50 Call Trace: i40e_free_rx_resources+0x70/0x80 [i40e] i40e_set_ringparam+0x27c/0x800 [i40e] ethnl_set_rings+0x1b2/0x290 genl_family_rcv_msg_doit.isra.15+0x10f/0x150 genl_family_rcv_msg+0xb3/0x160 ? rings_fill_reply+0x1a0/0x1a0 genl_rcv_msg+0x47/0x90 ? genl_family_rcv_msg+0x160/0x160 netlink_rcv_skb+0x4c/0x120 genl_rcv+0x24/0x40 netlink_unicast+0x196/0x230 netlink_sendmsg+0x204/0x3d0 sock_sendmsg+0x4c/0x50 __sys_sendto+0xee/0x160 ? handle_mm_fault+0xbe/0x1e0 ? syscall_trace_enter+0x1d3/0x2c0 __x64_sys_sendto+0x24/0x30 do_syscall_64+0x5b/0x1a0 entry_SYSCALL_64_after_hwframe+0x65/0xca RIP: 0033:0x7f5eac8b035b Missing register, driver bug WARNING: CPU: 0 PID: 4300 at net/core/xdp.c:119 xdp_rxq_info_unreg_mem_model+0x69/0x140 Call Trace: xdp_rxq_info_unreg+0x1e/0x50 i40e_free_rx_resources+0x70/0x80 [i40e] i40e_set_ringparam+0x27c/0x800 [i40e] ethnl_set_rings+0x1b2/0x290 genl_family_rcv_msg_doit.isra.15+0x10f/0x150 genl_family_rcv_msg+0xb3/0x160 ? rings_fill_reply+0x1a0/0x1a0 genl_rcv_msg+0x47/0x90 ? genl_family_rcv_msg+0x160/0x160 netlink_rcv_skb+0x4c/0x120 genl_rcv+0x24/0x40 netlink_unicast+0x196/0x230 netlink_sendmsg+0x204/0x3d0 sock_sendmsg+0x4c/0x50 __sys_sendto+0xee/0x160 ? handle_mm_fault+0xbe/0x1e0 ? syscall_trace_enter+0x1d3/0x2c0 __x64_sys_sendto+0x24/0x30 do_syscall_64+0x5b/0x1a0 entry_SYSCALL_64_after_hwframe+0x65/0xca RIP: 0033:0x7f5eac8b035b

This was caused because of new buffers with different RX ring count should substitute older ones, but those buffers were freed in i40e_configure_rx_ring and reallocated again with i40e_alloc_rx_bi, thus kfree on rx_bi caused leak of already mapped DMA.

Fix this by reallocating ZC with rx_bi_zc struct when BPF program loads. Additionally reallocate back to rx_bi when BPF program unloads.

If BPF program is loaded/unloaded and XSK pools are created, reallocate RX queues accordingly in XSP_SETUP_XSK_POOL handler.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2022-50679"
  ],
  "database_specific": {
    "cwe_ids": [],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-12-09T16:17:20Z",
    "severity": null
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\ni40e: Fix DMA mappings leak\n\nDuring reallocation of RX buffers, new DMA mappings are created for\nthose buffers.\n\nsteps for reproduction:\nwhile :\ndo\nfor ((i=0; i\u003c=8160; i=i+32))\ndo\nethtool -G enp130s0f0 rx $i tx $i\nsleep 0.5\nethtool -g enp130s0f0\ndone\ndone\n\nThis resulted in crash:\ni40e 0000:01:00.1: Unable to allocate memory for the Rx descriptor ring, size=65536\nDriver BUG\nWARNING: CPU: 0 PID: 4300 at net/core/xdp.c:141 xdp_rxq_info_unreg+0x43/0x50\nCall Trace:\ni40e_free_rx_resources+0x70/0x80 [i40e]\ni40e_set_ringparam+0x27c/0x800 [i40e]\nethnl_set_rings+0x1b2/0x290\ngenl_family_rcv_msg_doit.isra.15+0x10f/0x150\ngenl_family_rcv_msg+0xb3/0x160\n? rings_fill_reply+0x1a0/0x1a0\ngenl_rcv_msg+0x47/0x90\n? genl_family_rcv_msg+0x160/0x160\nnetlink_rcv_skb+0x4c/0x120\ngenl_rcv+0x24/0x40\nnetlink_unicast+0x196/0x230\nnetlink_sendmsg+0x204/0x3d0\nsock_sendmsg+0x4c/0x50\n__sys_sendto+0xee/0x160\n? handle_mm_fault+0xbe/0x1e0\n? syscall_trace_enter+0x1d3/0x2c0\n__x64_sys_sendto+0x24/0x30\ndo_syscall_64+0x5b/0x1a0\nentry_SYSCALL_64_after_hwframe+0x65/0xca\nRIP: 0033:0x7f5eac8b035b\nMissing register, driver bug\nWARNING: CPU: 0 PID: 4300 at net/core/xdp.c:119 xdp_rxq_info_unreg_mem_model+0x69/0x140\nCall Trace:\nxdp_rxq_info_unreg+0x1e/0x50\ni40e_free_rx_resources+0x70/0x80 [i40e]\ni40e_set_ringparam+0x27c/0x800 [i40e]\nethnl_set_rings+0x1b2/0x290\ngenl_family_rcv_msg_doit.isra.15+0x10f/0x150\ngenl_family_rcv_msg+0xb3/0x160\n? rings_fill_reply+0x1a0/0x1a0\ngenl_rcv_msg+0x47/0x90\n? genl_family_rcv_msg+0x160/0x160\nnetlink_rcv_skb+0x4c/0x120\ngenl_rcv+0x24/0x40\nnetlink_unicast+0x196/0x230\nnetlink_sendmsg+0x204/0x3d0\nsock_sendmsg+0x4c/0x50\n__sys_sendto+0xee/0x160\n? handle_mm_fault+0xbe/0x1e0\n? syscall_trace_enter+0x1d3/0x2c0\n__x64_sys_sendto+0x24/0x30\ndo_syscall_64+0x5b/0x1a0\nentry_SYSCALL_64_after_hwframe+0x65/0xca\nRIP: 0033:0x7f5eac8b035b\n\nThis was caused because of new buffers with different RX ring count should\nsubstitute older ones, but those buffers were freed in\ni40e_configure_rx_ring and reallocated again with i40e_alloc_rx_bi,\nthus kfree on rx_bi caused leak of already mapped DMA.\n\nFix this by reallocating ZC with rx_bi_zc struct when BPF program loads. Additionally\nreallocate back to rx_bi when BPF program unloads.\n\nIf BPF program is loaded/unloaded and XSK pools are created, reallocate\nRX queues accordingly in XSP_SETUP_XSK_POOL handler.",
  "id": "GHSA-75w2-9m25-jvqg",
  "modified": "2025-12-09T18:30:32Z",
  "published": "2025-12-09T18:30:32Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-50679"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/5f499596dfa3db9b3172645b6de9e1096a669c95"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/94a171c982b8a8137a00721c1e62bc2713435bca"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/aae425efdfd1b1d8452260a3cb49344ebf20b1f5"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/ed5baf3d0a33caaca4cd4073ebb0854cc77a616d"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…

Sightings

Author Source Type Date

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.


Loading…

Detection rules are retrieved from Rulezet.

Loading…

Loading…