CVE-2026-89506

What it actually does

A missing ioctl attribute on the Linux kernel RDMA uverbs register-memory-region path lets a local caller invoke REG_MR without hardware-private udata. The mthca, irdma, and siw drivers assume udata is never NULL and dereference it, causing a kernel NULL-pointer oops or panic (local denial of service). The defect is confined to local uverbs ioctl handling and does not by itself provide remote access, memory corruption for code execution, or privilege escalation.

Why it matters to the business

Linux hosts that load the affected RDMA drivers can be crashed by a local process that can open InfiniBand/RDMA device nodes, interrupting HPC, storage fabric, and other low-latency networking workloads and forcing reboots. The CVE is not in CISA KEV, is not associated with ransomware, has no reported in-the-wild use, and a very low, flat EPSS (~0.002 over 30 days), so opportunistic mass exploitation is unlikely; residual risk is still material for multi-tenant clusters and any environment where untrusted code can reach RDMA devices. It has been public for about a month, so unpatched RDMA fleets remain exposed until kernels are updated.

How an attack unfolds

An attacker who already has local code execution and permission to use RDMA uverbs devices issues the memory-region registration ioctl without the hardware-specific attribute those three drivers require. The kernel delivers a NULL udata pointer into driver REG_MR handling, which crashes the host or the RDMA stack. Legitimate rdma-core registration does not take this path, so the crash is from crafted userspace rather than normal applications. No named threat actors, public exploit modules, or ransomware campaigns are tied to this issue.

How to fix it

Install a Linux kernel that includes the RDMA/uverbs fix adding UVERBS_ATTR_UHW to UVERBS_METHOD_REG_MR so register-MR ioctls always supply valid udata, then reboot onto that kernel. Use your distribution’s kernel security advisory or upstream stable updates that absorbed this change; no per-package fixed-version list was supplied with this record. Until patched, restrict access to RDMA/InfiniBand device nodes to trusted users and groups, unload or blacklist unused mthca, irdma, and siw modules, and do not expose uverbs devices to untrusted tenants or containers.

How to confirm the fix worked

Confirm the running kernel changelog, CVE mapping, or distro package notes include the RDMA/uverbs REG_MR UVERBS_ATTR_UHW change. Inventory whether ib_mthca/mthca, irdma, or siw are loaded and whether /dev/infiniband uverbs nodes exist to measure exposure. After upgrade, verify legitimate RDMA memory registration still succeeds and that untrusted users cannot open uverbs devices if that is policy. Do not attempt to trigger the crash on production systems.

Typical attack path

1. Obtain local access on a Linux host that loads the mthca, irdma, or siw RDMA drivers
2. Open an RDMA uverbs character device with sufficient privileges
3. Issue the register-memory-region ioctl without the hardware-private udata attribute
4. Cause a NULL udata dereference in the driver, producing a kernel oops or panic
5. Repeat after reboot if local access remains, to prolong downtime

How to detect it

This flaw leaves a kernel oops or panic, not persistent malware, so hunt historical crash evidence rather than implants. Review dmesg, journalctl -k, kern.log, kdump/vmcore, and console panic logs on RDMA-capable hosts for NULL-pointer dereferences whose call traces include ib_uverbs and mthca, irdma, or siw, especially unexplained reboots after the mid-September 2026 publication window. Correlate with processes that opened InfiniBand uverbs devices (audit watches on /dev/infiniband, ioctl audit, or equivalent). There are no campaign-specific hashes or actor TTPs; treat unexplained crashes in those drivers as potentially related.

• BUG: kernel NULL pointer dereference
• Unable to handle kernel NULL pointer dereference
• Oops: 0000
• [ib_uverbs]
• [irdma]
• [ib_mthca]
• [siw]
• /dev/infiniband/uverbs

What your security team should do

• Patch and reboot RDMA-capable hosts (especially those loading mthca, irdma, or siw), even though EPSS is low and the issue is not in KEV
• Restrict permissions on /dev/infiniband and related uverbs nodes so untrusted users and containers cannot issue RDMA ioctls
• Unload or blacklist unused RDMA drivers to reduce attack surface
• Watch kernel logs and crash dumps for NULL-pointer oopses involving ib_uverbs and the three named drivers
• Track vendor kernel advisories until all RDMA fleets are confirmed patched