CVE-2026-89509

What it actually does

The Linux kernel ionic RDMA driver fails to embed struct rdma_counter in a driver-private object, register INIT_RDMA_OBJ_SIZE, or supply counter_init. rdma_zalloc_drv_obj() therefore allocates a zero-byte object; later use in alloc_and_bind() NULL-dereferences and oopses the kernel, causing a host crash (DoS) on systems with the ionic RDMA driver.

Why it matters to the business

Servers that use Ionic/Pensando RDMA NICs can panic and drop out of service if the RDMA counter path is exercised, interrupting RDMA-dependent workloads until reboot and patching. The CVE is not in CISA KEV, has no known ransomware use, exploit maturity is none, and EPSS is ~0.21% and flat over 30 days, so opportunistic mass exploitation is unlikely. Impact is confined to hosts with this driver/hardware; general-purpose fleets without Ionic RDMA are not affected.

How an attack unfolds

After RDMA core began allocating counters with rdma_zalloc_drv_obj(), drivers must embed rdma_counter, declare object size, and implement counter_init. Ionic shipped without that adaptation, so counter allocation yields no backing storage. A local or otherwise privileged actor who can trigger RDMA counter allocate-and-bind on a vulnerable ionic device causes a NULL-pointer dereference and kernel oops. There are no named threat actors, public exploits, or KEV listings for this issue; it is an availability crash, not a privilege-escalation or remote code-execution primitive.

How to fix it

Apply the upstream Linux kernel RDMA/ionic fix that consolidates driver counter state into a struct embedding rdma_counter, switches ID allocation to an IDA, and adds counter_init plus INIT_RDMA_OBJ_SIZE. Upgrade to a distribution kernel that includes that change. Where a fixed kernel is not yet available, unload or blacklist the ionic RDMA module on systems that do not need Ionic RDMA, and restrict who can create RDMA resources. No per-package fixed versions were published with this record—track vendor kernel advisories.

How to confirm the fix worked

Confirm the running kernel includes the ionic_rdma_counter embedding, counter_init, and INIT_RDMA_OBJ_SIZE changes (kernel changelog, vendor advisory, or module/source inspection). Inventory hosts for Ionic RDMA hardware and a loaded ionic RDMA module. After patching, in a maintenance window allocate/bind RDMA counters on representative Ionic hosts and verify no oops. Hosts without the module loaded are not exposed.

Typical attack path

1. Gain local or equivalently privileged access on a host running a vulnerable kernel with the ionic RDMA driver loaded and Ionic hardware present.
2. Cause the RDMA stack to allocate and bind a performance counter so alloc_and_bind() runs against the zero-sized ionic counter object.
3. Kernel NULL-pointer dereference oopses or panics the host, denying service until reboot.

How to detect it

Successful abuse looks like a kernel oops/panic, not persistence or C2. Search dmesg, journalctl kernel logs, kdump/vmcore, and serial/console crash captures around the published date for NULL-pointer dereference reports whose call trace includes ionic RDMA or alloc_and_bind/rdma_counter. Correlate with hosts that have Ionic NICs and the ionic RDMA module loaded. There are no associated APT campaigns; repeated crashes on counter bind without a matching kernel update are the primary post-exploitation signal.

• BUG: kernel NULL pointer dereference
• Call Trace:.*ionic
• alloc_and_bind
• rdma_zalloc_drv_obj
• size_rdma_counter
• Oops:.*ionic

What your security team should do

• Inventory hosts with Ionic/Pensando RDMA NICs or a loaded ionic RDMA kernel module and treat those as the only in-scope assets.
• Patch those kernels to a build that includes the RDMA/ionic counter allocation fix as soon as the distro ships it.
• Unload or blacklist the ionic RDMA driver on machines that do not use the hardware.
• Monitor kernel logs and crash dumps for ionic/RDMA NULL-pointer oopses; this is not a KEV item and EPSS is low, so prioritize behind actively exploited kernel bugs unless you run RDMA-heavy clusters.
• Do not expect remote unauthenticated exploitation; focus on local/privileged access control to the RDMA stack.