Linux kernel RDMA/ionic: NULL dereference allocating an RDMA counter on AMD Pensando DPUs

Impact

The ionic RDMA driver was merged without the counter-object adaptation that RDMA core now requires: it never registers size_rdma_counter or a counter_init callback, so rdma_zalloc_drv_obj() allocates zero bytes and alloc_and_bind() dereferences NULL. Anyone who configures per-QP statistics counters on an ionic device takes the host kernel down, which on a GPU node means an unplanned loss of every job on it. Exposure is narrow: it only affects fleets running AMD Pensando DPUs with the ionic RDMA driver, and driving the counter path normally takes privileges on the RDMA netlink interface rather than tenant-level access. Treat it as an availability bug in a specific NIC driver, not a tenant escape.

Who can reach it

Local administrator or process able to create and bind RDMA counters through RDMA netlink (the rdma statistic tooling) on a host with an ionic RDMA device. Not reachable on nodes without that hardware.

What to do

Update to a kernel containing the fix (three stable commits linked; it consolidates the counter struct and adds the required declarations) and reboot the affected nodes. Until then, avoid configuring per-QP RDMA counters on ionic devices. No fixed release numbers are stated in the record.

References

Related entries

• Linux kernel RDMA/cxgb4: use-after-free if device removal races the deferred RDMA registration workCVE-2026-89510 · Linux kernel RDMA/cxgb4 (c4iw_remove vs pending reg_work)Unscored
• Linux kernel ACPI Platform Firmware Runtime Update: firmware-supplied length overflows a stack bufferCVE-2026-89587 · Linux kernel ACPI pfr_update (query_capability _DSM buffer copy)Unscored
• Linux kernel APEI GHES: wrong sizeof lets ARM error-record parsing read past the CPER sectionCVE-2026-89588 · Linux kernel ACPI APEI GHES (ARM processor CPER section length accounting)Unscored
• ASPEED BMC (host-to-BMC bridges generally): The ASPEED LPC/PCIe bridge architecture exists to let the host talkNCVD-0000-001-aspeed-bmc-host-to-bmc-bridges-g · ASPEED BMC (host-to-BMC bridges generally)Unscored
• IPMI over LAN as a protocol: IPMI has no transport confidentiality guarantees worth relying on, weak session handlingNCVD-0000-002-ipmi-over-lan-as-a-protocol · IPMI over LAN as a protocolUnscored
• Internet-exposed BMC: Shodan-visible BMCs are a recurring finding at colo/neocloud buildoutsNCVD-0000-003-internet-exposed-bmc · Internet-exposed BMCUnscored