GHSA-XQ3R-74HW-4C5P

Vulnerability from github – Published: 2026-05-27 15:33 – Updated: 2026-05-27 15:33
VLAI
Details

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

RDMA/uverbs: Validate wqe_size before using it in ib_uverbs_post_send

ib_uverbs_post_send() uses cmd.wqe_size from userspace without any validation before passing it to kmalloc() and using the allocated buffer as struct ib_uverbs_send_wr.

If a user provides a small wqe_size value (e.g., 1), kmalloc() will succeed, but subsequent accesses to user_wr->opcode, user_wr->num_sge, and other fields will read beyond the allocated buffer, resulting in an out-of-bounds read from kernel heap memory. This could potentially leak sensitive kernel information to userspace.

Additionally, providing an excessively large wqe_size can trigger a WARNING in the memory allocation path, as reported by syzkaller.

This is inconsistent with ib_uverbs_unmarshall_recv() which properly validates that wqe_size >= sizeof(struct ib_uverbs_recv_wr) before proceeding.

Add the same validation for ib_uverbs_post_send() to ensure wqe_size is at least sizeof(struct ib_uverbs_send_wr).

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-45856"
  ],
  "database_specific": {
    "cwe_ids": [],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-05-27T14:16:57Z",
    "severity": null
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/uverbs: Validate wqe_size before using it in ib_uverbs_post_send\n\nib_uverbs_post_send() uses cmd.wqe_size from userspace without any\nvalidation before passing it to kmalloc() and using the allocated\nbuffer as struct ib_uverbs_send_wr.\n\nIf a user provides a small wqe_size value (e.g., 1), kmalloc() will\nsucceed, but subsequent accesses to user_wr-\u003eopcode, user_wr-\u003enum_sge,\nand other fields will read beyond the allocated buffer, resulting in\nan out-of-bounds read from kernel heap memory. This could potentially\nleak sensitive kernel information to userspace.\n\nAdditionally, providing an excessively large wqe_size can trigger a\nWARNING in the memory allocation path, as reported by syzkaller.\n\nThis is inconsistent with ib_uverbs_unmarshall_recv() which properly\nvalidates that wqe_size \u003e= sizeof(struct ib_uverbs_recv_wr) before\nproceeding.\n\nAdd the same validation for ib_uverbs_post_send() to ensure wqe_size\nis at least sizeof(struct ib_uverbs_send_wr).",
  "id": "GHSA-xq3r-74hw-4c5p",
  "modified": "2026-05-27T15:33:13Z",
  "published": "2026-05-27T15:33:13Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-45856"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/01c9b152647dc70dc06a4a2eff86ebb3b3c76075"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/1956f0a74ccf5dc9c3ef717f2985c3ed3400aab0"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/9b5ac1c15334d46c0dbd49d64a2257b929500163"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/9c15ec4cd4e7f57c6bbcb4e73e99290f150dd2a7"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/bef70ff9841990658610512b4a18e4a88c9b4df6"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/bf1feed1a7886af945f92890493aefd2b5c9928a"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/bf4454da8b1e712714628c0a0d6e7845bb40790a"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/d533425ac1f2925b4fc3e4ed9b9d72362cb23475"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.





Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

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.


Detection rules are retrieved from Rulezet.