GHSA-4GFV-WQF7-R3G7

Vulnerability from github – Published: 2025-12-24 15:30 – Updated: 2025-12-24 15:30
VLAI?
Details

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

RDMA/bnxt_re: Prevent handling any completions after qp destroy

HW may generate completions that indicates QP is destroyed. Driver should not be scheduling any more completion handlers for this QP, after the QP is destroyed. Since CQs are active during the QP destroy, driver may still schedule completion handlers. This can cause a race where the destroy_cq and poll_cq running simultaneously.

Snippet of kernel panic while doing bnxt_re driver load unload in loop. This indicates a poll after the CQ is freed. 

[77786.481636] Call Trace: [77786.481640]   [77786.481644]  bnxt_re_poll_cq+0x14a/0x620 [bnxt_re] [77786.481658]  ? kvm_clock_read+0x14/0x30 [77786.481693]  __ib_process_cq+0x57/0x190 [ib_core] [77786.481728]  ib_cq_poll_work+0x26/0x80 [ib_core] [77786.481761]  process_one_work+0x1e5/0x3f0 [77786.481768]  worker_thread+0x50/0x3a0 [77786.481785]  ? __pfx_worker_thread+0x10/0x10 [77786.481790]  kthread+0xe2/0x110 [77786.481794]  ? __pfx_kthread+0x10/0x10 [77786.481797]  ret_from_fork+0x2c/0x50

To avoid this, complete all completion handlers before returning the destroy QP. If free_cq is called soon after destroy_qp, IB stack will cancel the CQ work before invoking the destroy_cq verb and this will prevent any race mentioned.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2023-54048"
  ],
  "database_specific": {
    "cwe_ids": [],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-12-24T13:16:06Z",
    "severity": null
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/bnxt_re: Prevent handling any completions after qp destroy\n\nHW may generate completions that indicates QP is destroyed.\nDriver should not be scheduling any more completion handlers\nfor this QP, after the QP is destroyed. Since CQs are active\nduring the QP destroy, driver may still schedule completion\nhandlers. This can cause a race where the destroy_cq and poll_cq\nrunning simultaneously.\n\nSnippet of kernel panic while doing bnxt_re driver load unload in loop.\nThis indicates a poll after the CQ is freed.\u00a0\n\n[77786.481636] Call Trace:\n[77786.481640] \u00a0\u003cTASK\u003e\n[77786.481644] \u00a0bnxt_re_poll_cq+0x14a/0x620 [bnxt_re]\n[77786.481658] \u00a0? kvm_clock_read+0x14/0x30\n[77786.481693] \u00a0__ib_process_cq+0x57/0x190 [ib_core]\n[77786.481728] \u00a0ib_cq_poll_work+0x26/0x80 [ib_core]\n[77786.481761] \u00a0process_one_work+0x1e5/0x3f0\n[77786.481768] \u00a0worker_thread+0x50/0x3a0\n[77786.481785] \u00a0? __pfx_worker_thread+0x10/0x10\n[77786.481790] \u00a0kthread+0xe2/0x110\n[77786.481794] \u00a0? __pfx_kthread+0x10/0x10\n[77786.481797] \u00a0ret_from_fork+0x2c/0x50\n\nTo avoid this, complete all completion handlers before returning the\ndestroy QP. If free_cq is called soon after destroy_qp,  IB stack\nwill cancel the CQ work before invoking the destroy_cq verb and\nthis will prevent any race mentioned.",
  "id": "GHSA-4gfv-wqf7-r3g7",
  "modified": "2025-12-24T15:30:35Z",
  "published": "2025-12-24T15:30:35Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-54048"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/7faa6097694164380ed19600c7a7993d071270b9"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/b5bbc6551297447d3cca55cf907079e206e9cd82"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/b79a0e71d6e8692e0b6da05f8aaa7d69191cf7e7"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/b8500538b8f5b2cd86b02754c8de83eaa7a2d6ba"
    }
  ],
  "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…