CVE-2026-89505

What it actually does

An uninitialized-pointer dereference in the Linux kernel RDMA InfiniBand userspace verbs (uverbs) legacy write() path. The uverbs_attr_bundle used by that path has no ioctl method element, so if malformed provider input causes common uverbs validation to emit an error, uverbs_get_handler_fn() reads an uninitialized method_elm pointer. The result is kernel memory corruption that typically manifests as an oops or panic (availability loss) and, depending on residual stack contents, could theoretically enable further kernel memory safety violations. The ioctl path is not the same dispatcher; the defect is specific to legacy write() bundles lacking method_elm.

Why it matters to the business

Hosts that expose RDMA/InfiniBand uverbs (HPC, high-performance storage, GPU fabrics, and some cloud networking) can be crashed by a local unprivileged or low-privilege process that can open the uverbs device, causing node outages, job interruption, and failover events. Exploitation maturity is none, the CVE is not in CISA KEV, ransomware use is not reported, and EPSS remains very low and flat (~0.002 over 30 days), so mass opportunistic exploitation is unlikely. Residual risk is still material for RDMA-enabled production fleets because a single local crash can take down a compute or storage node. There is no public per-distro fixed-version list in this record; treat vendor kernel updates as the control.

How an attack unfolds

An attacker who already has local code execution on a Linux system with RDMA uverbs available opens the legacy InfiniBand uverbs character device and issues a write() that the kernel treats as a legacy uverbs method. The request is crafted so that shared uverbs attribute validation fails and attempts to report an error. That error path calls uverbs_get_handler_fn(), which assumes an ioctl method element is present and dereferences the uninitialized method_elm pointer on the legacy bundle. The kernel then faults. No named threat actors, KEV activity, or in-the-wild campaigns are associated with this issue; the realistic outcome with current public information is a local denial of service rather than a turnkey privilege-escalation exploit.

How to fix it

Apply the upstream Linux kernel fix that initializes method_elm for legacy uverbs bundles and makes uverbs_get_handler_fn() return NULL when no ioctl method is present, so the legacy dispatcher keeps using its local write method. Deploy the corresponding stable/longterm kernel or distribution package as soon as the vendor ships it; no exact package versions are listed in this record, so follow distro/kernel-vendor advisories for the RDMA/uverbs change. Until patched, restrict who can open InfiniBand uverbs devices (device node permissions, cgroup device policy, and removal of RDMA capabilities from untrusted tenants/containers), and avoid exposing uverbs into untrusted namespaces. Systems without RDMA hardware or with ib_uverbs unloaded are not in the attack surface.

How to confirm the fix worked

Confirm the running kernel includes the RDMA/uverbs guard for legacy bundles without method_elm (vendor changelog, git commit in the RDMA/uverbs tree, or package notes). On representative RDMA hosts, verify ib_uverbs is the expected patched build, that /dev/infiniband/uverbs* permissions match policy, and that untrusted workloads cannot open those nodes. After patching, regression-test legitimate uverbs write() and ioctl clients and confirm that invalid legacy write() input no longer oopses in uverbs_get_handler_fn. Hosts without RDMA devices or with the module blacklisted can be recorded as not exposed.

Typical attack path

1. Gain local access on a Linux host that has RDMA/InfiniBand userspace verbs enabled (for example via /dev/infiniband/uverbs*).
2. Open the legacy uverbs character device and use the write() interface rather than the ioctl method path.
3. Submit malformed uverbs provider input that fails common attribute validation and triggers the error-reporting path.
4. Cause uverbs_get_handler_fn() to dereference the uninitialized method_elm pointer on a legacy bundle that has no ioctl method element.
5. Induce a kernel oops/panic (denial of service) or other memory-corruption side effects in the RDMA stack.

How to detect it

This defect leaves no reliable network C2 pattern; look for local kernel faults on RDMA hosts after the publication date (2026-09-11). Review dmesg, journalctl -k, kdump/vmcore, and panic consoles for oopses in ib_uverbs / RDMA uverbs, especially RIP or call traces naming uverbs_get_handler_fn, uverbs attribute validation, or the legacy write dispatcher. Correlate with processes that had /dev/infiniband/uverbs* open (audit SYSCALL records for that device, fanotify/audit watches, or crash-time fd tables). Sudden node reboots or RDMA job failures without hardware errors are worth triaging. No named APT campaigns are documented, so treat matching oopses as local DoS or crash-for-bug rather than a known ransomware signature.

• uverbs_get_handler_fn
• ib_uverbs
• /dev/infiniband/uverbs
• uverbs_attr_bundle
• method_elm
• uverbs_api_write_method
• Call Trace: ib_uverbs
• Oops:.*uverbs
• kernel BUG at drivers/infiniband/core

What your security team should do

• Inventory Linux hosts with RDMA/InfiniBand (ib_uverbs loaded, /dev/infiniband/uverbs* present) and prioritize kernel updates there; non-RDMA fleets are lower urgency.
• Track and apply vendor kernel packages that contain the uverbs method_elm initialization / NULL-handler fix; do not wait for KEV given this is still kernel memory corruption.
• Until patched, lock down uverbs device nodes and RDMA capabilities for untrusted users, containers, and multi-tenant jobs.
• Because EPSS is ~0.002, exploit maturity is none, and the CVE is not in KEV, treat this as a scheduled kernel-hardening item rather than an emergency internet-facing incident—unless RDMA is exposed to untrusted local tenants.
• Add kernel-oops monitoring for ib_uverbs / uverbs_get_handler_fn so a crash is treated as a potential local abuse attempt, not only a hardware glitch.