CVE-2026-45856

What it actually does

This is a local Linux kernel vulnerability in the RDMA userspace verbs interface. The affected ib_uverbs_post_send() path accepts a userspace-controlled wqe_size value without first confirming that it is large enough to contain a struct ib_uverbs_send_wr. If a local user with access to an RDMA uverbs character device supplies an undersized work-queue-entry size, the kernel may allocate a too-small buffer and then read fields beyond that allocation from adjacent kernel heap memory. The primary impact is potential disclosure of sensitive kernel memory to userspace. Supplying an excessively large wqe_size may also trigger kernel memory-allocation warnings and contribute to local denial-of-service conditions.

Why it matters to the business

Systems exposing Linux RDMA userspace devices to local users, containers, HPC workloads, virtualization guests, or shared compute tenants may allow a low-privileged user to read sensitive kernel memory or destabilize the host. The risk is most relevant to servers using InfiniBand, RoCE, iWARP, or other RDMA-capable hardware and drivers. EPSS is currently low and there is no known CISA KEV listing or public exploit maturity reported, but the bug affects kernel isolation boundaries and should be prioritized on multi-user or shared infrastructure.

How an attack unfolds

An attacker first obtains local code execution on a Linux system where RDMA userspace verbs are available and the attacker can open an affected /dev/infiniband/uverbs* device. The attacker then issues an RDMA uverbs post-send operation with a malformed userspace command that sets wqe_size smaller than the expected send work request structure. The vulnerable kernel path allocates memory based on the attacker-supplied size and later reads fields such as opcode and num_sge as though the full structure were present. Those reads can cross the end of the allocated object and expose adjacent kernel heap contents back through the syscall/ioctl behavior or error-handling paths. Alternatively, an attacker may provide an excessively large value to trigger allocation-path warnings and potentially degrade local system stability.

How to fix it

Upgrade to a Linux kernel version that includes the RDMA/uverbs fix validating that wqe_size is at least sizeof(struct ib_uverbs_send_wr) before ib_uverbs_post_send() uses it. If vendor fixed package versions are not yet available, track the relevant distribution kernel advisories and apply the first patched kernel released for the affected branch. Reboot into the patched kernel after installation; merely installing the package is not sufficient if the vulnerable kernel remains running. Where immediate patching is not possible, reduce exposure by disabling unused RDMA functionality, unloading or blocking RDMA/uverbs modules where feasible, restricting access to /dev/infiniband/uverbs* devices, and avoiding delegation of RDMA device access into untrusted containers or shared user environments.

How to confirm the fix worked

Confirm the running kernel, not just the installed package, has been updated to a vendor build containing the RDMA/uverbs wqe_size validation fix. Verify with uname -a, distribution package metadata, and the applicable vendor security advisory or kernel changelog. Confirm whether RDMA uverbs devices remain exposed by checking for /dev/infiniband/uverbs* and loaded modules such as ib_uverbs, rdma_ucm, and provider-specific RDMA drivers. On mitigated systems, ensure untrusted users and containers cannot open RDMA uverbs device nodes. Review kernel logs after remediation to confirm there are no recurring RDMA/uverbs allocation warnings or related kernel WARN traces.

Typical attack path

1. Gain local execution as an unprivileged or low-privileged user on a Linux system.
2. Determine whether RDMA userspace verbs are present by checking for /dev/infiniband/uverbs* devices and loaded RDMA modules such as ib_uverbs.
3. Open an accessible RDMA uverbs device.
4. Send a crafted ib_uverbs post-send request with an invalid wqe_size value.
5. Use an undersized wqe_size to cause out-of-bounds kernel heap reads during parsing of the send work request.
6. Collect leaked kernel memory if exposed through the operation’s response or observable behavior.
7. Optionally use oversized wqe_size values to trigger kernel allocation warnings or local instability.

How to detect it

Look for signs of local probing or exploitation in kernel logs, audit logs, and device-access telemetry. Relevant log sources include dmesg, journald, /var/log/kern.log, /var/log/messages, auditd records for character device access, EDR process telemetry, and container runtime device-mount configuration. Exploitation may not always leave a reliable application-level trace, especially when using undersized requests for information disclosure, so absence of logs does not prove absence of exploitation. Focus on unexpected opens of /dev/infiniband/uverbs* by non-RDMA applications, untrusted users, containers, scripting runtimes, fuzzers, or newly dropped binaries. For denial-of-service style attempts, search for kernel WARN/Oops traces involving ib_uverbs_post_send, RDMA/uverbs, kmalloc, or memory allocation warnings near the time of suspicious local activity. If auditd is enabled, correlate uverbs device opens and ioctl activity with user identity, process lineage, container identity, and any subsequent privilege-escalation or credential-access behavior.

• /dev/infiniband/uverbs0
• /dev/infiniband/uverbs1
• /dev/infiniband/uverbs
• ib_uverbs_post_send
• RDMA/uverbs
• ib_uverbs
• wqe_size
• struct ib_uverbs_send_wr
• WARNING: CPU:
• kernel: WARNING
• kmalloc
• allocation failure
• Call Trace:
• RIP: ib_uverbs_post_send
• audit: type=PATH msg= name="/dev/infiniband/uverbs0"
• audit: type=PATH msg= name="/dev/infiniband/uverbs1"
• audit: type=SYSCALL msg= syscall=open
• audit: type=SYSCALL msg= syscall=openat
• audit: type=SYSCALL msg= syscall=ioctl

What your security team should do

• Inventory Linux systems with RDMA-capable hardware, /dev/infiniband/uverbs* devices, or loaded ib_uverbs modules.
• Prioritize patching multi-user servers, HPC clusters, container hosts, virtualization platforms, and any systems where untrusted users can access RDMA devices.
• Apply vendor-patched kernel updates and reboot into the fixed kernel.
• If patching is delayed, restrict permissions on /dev/infiniband/uverbs* and remove RDMA device passthrough from untrusted containers or workloads.
• Disable or blacklist unused RDMA/uverbs modules on systems that do not require RDMA functionality.
• Monitor kernel logs for RDMA/uverbs warnings, allocation warnings, and abnormal local crashes until remediation is complete.
• Treat any confirmed exploitation on shared infrastructure as a potential kernel memory disclosure incident and assess whether sensitive credentials or secrets may have been resident in memory.