CVE-2026-45856

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).

Weakness

The product reads data past the end, or before the beginning, of the intended buffer.

Affected Software

Potential Mitigations

• Assume all input is malicious. Use an “accept known good” input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does.
• When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, “boat” may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as “red” or “blue.”
• Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code’s environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.
• To reduce the likelihood of introducing an out-of-bounds read, ensure that you validate and ensure correct calculations for any length argument, buffer size calculation, or offset. Be especially careful of relying on a sentinel (i.e. special character such as NUL) in untrusted inputs.

Related Attack Patterns

• https://cwe.mitre.org/data/definitions/540.html

References

• https://git.kernel.org/stable/c/01c9b152647dc70dc06a4a2eff86ebb3b3c76075
• https://git.kernel.org/stable/c/1956f0a74ccf5dc9c3ef717f2985c3ed3400aab0
• https://git.kernel.org/stable/c/9b5ac1c15334d46c0dbd49d64a2257b929500163
• https://git.kernel.org/stable/c/9c15ec4cd4e7f57c6bbcb4e73e99290f150dd2a7
• https://git.kernel.org/stable/c/bef70ff9841990658610512b4a18e4a88c9b4df6
• https://git.kernel.org/stable/c/bf1feed1a7886af945f92890493aefd2b5c9928a
• https://git.kernel.org/stable/c/bf4454da8b1e712714628c0a0d6e7845bb40790a
• https://git.kernel.org/stable/c/d533425ac1f2925b4fc3e4ed9b9d72362cb23475