CVE-2026-89510

What it actually does

A use-after-free race in the Linux kernel Chelsio cxgb4 iWARP/RDMA driver (iw_cxgb4) lets asynchronous registration work (reg_work queued from c4iw_uld_state_change) run after c4iw_remove() has freed the device context. c4iw_register_device() then dereferences freed kernel memory, enabling heap corruption with local high-impact confidentiality, integrity, and availability loss (kernel panic or potential privilege escalation to ring 0).

Why it matters to the business

Linux hosts using Chelsio T4/T5 RDMA adapters can be crashed or fully taken over by a local low-privileged user, interrupting HPC, storage, and other RDMA-dependent services and exposing all data on the machine. Exploitation likelihood is currently low: EPSS is ~0.0018 and flat over 30 days, the issue is not in CISA KEV, ransomware use is not reported, and exploit maturity is none. Impact remains high wherever the driver is loaded; at 32 days after publication, vendor kernel updates should already be applied.

How an attack unfolds

An attacker with an existing local login on a Linux system that loads iw_cxgb4 induces an RDMA device registration/state-change so reg_work is queued, then forces device removal or driver teardown so c4iw_remove() frees the device while the work item is still pending or running. c4iw_register_device() operates on freed kernel memory; the resulting use-after-free can panic the host or, if heap layout is favorable, be abused for local privilege escalation. There is no remote vector, and no named threat actors or ransomware campaigns are associated with this issue.

How to fix it

Install the Linux kernel security update from your distribution that includes the RDMA/cxgb4 fix to cancel reg_work before device teardown and to skip a second unregister/deallocate when registration already tore down the device. Reboot into the patched kernel. Exact package versions were not supplied with this record; confirm presence of the fix via vendor CVE trackers and kernel changelogs. If Chelsio RDMA is not required, unload and blacklist iw_cxgb4 (and related cxgb4 modules) and restrict unprivileged ability to unbind or remove RDMA/PCI devices until patched.

How to confirm the fix worked

Confirm the running kernel or distro advisory includes CVE-2026-89510 or the upstream 'RDMA/cxgb4: Cancel reg_work before freeing device on remove' change. Inventory Chelsio T4/T5 adapters and whether iw_cxgb4 is loaded. After patching, in a non-production test system, exercise RDMA device registration and removal and verify there are no KASAN use-after-free reports, workqueue warnings, or oopses in c4iw_register_device, c4iw_remove, or c4iw_uld_state_change.

Typical attack path

1. Obtain local unprivileged access on a Linux host with Chelsio cxgb4 RDMA hardware and iw_cxgb4 loaded
2. Cause an RDMA device registration or ULD state change that queues reg_work
3. Concurrently trigger device removal, unbind, or driver teardown so the device context is freed while the work item is still live
4. Win the race so c4iw_register_device() touches freed kernel memory
5. Convert the use-after-free into a kernel panic (denial of service) or further kernel-heap abuse for local privilege escalation

How to detect it

This is a local kernel use-after-free; there are no reliable network signatures. Hunt dmesg, journalctl -k, /var/log/kern.log, and kdump/vmcore crash dumps for oops, BUG, or KASAN use-after-free reports whose call traces include iw_cxgb4, c4iw_register_device, c4iw_remove, or c4iw_uld_state_change, especially near PCI unbind, module unload, or RDMA device deletion. Correlate timestamps with local logins and device-remove events. Successful silent escalation may leave few artifacts; also review unexpected root processes or kernel taint/oops counters after cxgb4-related workqueue activity. Absence of crashes does not prove the bug was never hit.

• c4iw_register_device
• c4iw_uld_state_change
• c4iw_remove
• iw_cxgb4
• BUG: KASAN: use-after-free
• Use-after-free in c4iw
• Call Trace:.*c4iw_
• Workqueue:.*c4iw
• Oops:.*iw_cxgb4
• Unable to handle kernel paging request

What your security team should do

• Inventory Linux hosts with Chelsio RDMA NICs or iw_cxgb4/cxgb4 loaded and patch-and-reboot those kernels first
• Treat remaining unpatched driver-loaded hosts as a local privilege-escalation and crash risk despite low EPSS and no KEV listing
• If RDMA/iWARP on Chelsio adapters is unused, unload and blacklist the modules as a compensating control
• Limit local unprivileged access and the ability to unbind PCI/RDMA devices until the kernel update is confirmed
• Watch kernel logs and crash dumps for oops/KASAN hits in c4iw_* / iw_cxgb4 around device removal