RDMA/uverbs: Validate wqe_size before using it in ib_uverbs_post_send
- Published
- Last modified
- Where the record stands: published, rejected by its publisher, or superseded by another id.What do these mean? →
- published
- Whether CISA lists it in its Known Exploited Vulnerabilities catalog: proof that attackers are using it.What do these mean? →
- Not listed in CISA KEV
- Fix
- Fixed in 5.10.252, 5.15.202, 6.1.165, 6.6.128, 6.12.75, and 2 more
- Whether working attack code is public (Exploit-DB, Metasploit, Nuclei or GitHub). Public code makes attacks easier.What do these mean? →
- None on Exploit-DB, Metasploit or GitHub
- Exploitation: none
- Automatable: no
- Technical impact: partial
Summary
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).
Timeline
- CVE published
- CISA SSVC assessment
Exploitation: none · Automatable: no · Technical impact: partial
- Record last updated
Affected versions
- Linux Linux
From c3bea3d2dc5358e05541527283279102383b0231 · fixed in 9c15ec4cd4e7f57c6bbcb4e73e99290f150dd2a7; From c3bea3d2dc5358e05541527283279102383b0231 · fixed in 9b5ac1c15334d46c0dbd49d64a2257b929500163; From c3bea3d2dc5358e05541527283279102383b0231 · fixed in 01c9b152647dc70dc06a4a2eff86ebb3b3c76075; From c3bea3d2dc5358e05541527283279102383b0231 · fixed in bf1feed1a7886af945f92890493aefd2b5c9928a; From c3bea3d2dc5358e05541527283279102383b0231 · fixed in d533425ac1f2925b4fc3e4ed9b9d72362cb23475; From c3bea3d2dc5358e05541527283279102383b0231 · fixed in bf4454da8b1e712714628c0a0d6e7845bb40790a; From c3bea3d2dc5358e05541527283279102383b0231 · fixed in bef70ff9841990658610512b4a18e4a88c9b4df6; From c3bea3d2dc5358e05541527283279102383b0231 · fixed in 1956f0a74ccf5dc9c3ef717f2985c3ed3400aab0
- Linux Linux
5.0
- KernelLinux
From 5.0.0 · fixed in 5.10.252; From 5.11.0 · fixed in 5.15.202; From 5.16.0 · fixed in 6.1.165; From 6.2.0 · fixed in 6.6.128; From 6.7.0 · fixed in 6.12.75; From 6.13.0 · fixed in 6.18.14; From 6.19.0 · fixed in 6.19.4
References 8
git.kernel.org
- stable/c/9c15ec4cd4e7f57c6bbcb4e73e99290f150dd2a7
- stable/c/9b5ac1c15334d46c0dbd49d64a2257b929500163
- stable/c/01c9b152647dc70dc06a4a2eff86ebb3b3c76075
- stable/c/bf1feed1a7886af945f92890493aefd2b5c9928a
- stable/c/d533425ac1f2925b4fc3e4ed9b9d72362cb23475
- stable/c/bf4454da8b1e712714628c0a0d6e7845bb40790a
- stable/c/bef70ff9841990658610512b4a18e4a88c9b4df6
- stable/c/1956f0a74ccf5dc9c3ef717f2985c3ed3400aab0