CVE-2026-98353: Linux Kernel RDMA/erdma DoS Vulnerability

CVE-2026-98353 Overview

CVE-2026-98353 is a Linux kernel vulnerability in the RDMA erdma driver. The flaw involves non-IRQ-safe XArray helpers used for Queue Pair (QP) and Completion Queue (CQ) table management. Interrupt handlers performing locked QP and CQ lookups from Event Queue (EQ) interrupts can deadlock with create-path XArray updates holding the plain xa_lock. The resolution switches to IRQ-safe XArray helpers and initializes both arrays with XA_FLAGS_LOCK_IRQ so sleeping allocations preserve interrupt state.

Critical Impact
A deadlock in the erdma RDMA driver can hang kernel threads performing RDMA operations, leading to a denial-of-service condition on affected systems.

Affected Products

Linux kernel versions containing the drivers/infiniband/hw/erdma driver prior to the fix
Systems using Alibaba Elastic RDMA (eRDMA) network adapters
Stable kernel branches referenced by the upstream fix commits

Discovery Timeline

2026-10-06 - CVE-2026-98353 published to NVD
2026-10-06 - Last updated in NVD database

Technical Details for CVE-2026-98353

Vulnerability Analysis

The vulnerability resides in the Alibaba Elastic RDMA (erdma) kernel driver. The driver maintains XArray tables indexed by QP and CQ identifiers for fast lookup during both control-path operations and interrupt handling. The create path acquired the plain xa_lock while inserting new entries. The EQ interrupt handler performs lookups that also attempt to take the same lock. If an interrupt fires on the same CPU while the create path holds the non-IRQ-safe lock, the interrupt context spins waiting for a lock that cannot be released until the interrupt returns. This produces a classic self-deadlock.

The outcome is a kernel soft-lockup or hang affecting RDMA-dependent workloads. Although the issue is a reliability defect rather than a direct memory-safety flaw, availability impact on systems running RDMA-dependent services such as storage fabrics, HPC jobs, or distributed databases can be significant.

Root Cause

The root cause is incorrect synchronization primitive selection. The erdma driver used plain XArray helpers (for example xa_store and xa_lock) for QP and CQ tables that are accessed from both process context and hard IRQ context. Linux locking rules require IRQ-safe variants (xa_store_irq / xa_lock_irq) when a lock can be acquired from interrupt handlers, and the arrays must be initialized with XA_FLAGS_LOCK_IRQ so sleeping allocation paths restore interrupt state correctly.

Attack Vector

Triggering the condition requires workload patterns that generate concurrent QP or CQ create operations alongside EQ interrupt delivery on the same CPU. The condition is a race between a kernel create path and an asynchronous device interrupt, so exploitation is not a remote vector in the traditional sense. A local workload that creates and tears down RDMA resources under heavy traffic can reach the deadlock state. No proof-of-concept or in-the-wild exploitation has been reported, and the issue has no CWE assignment at publication time.

See the upstream resolution in the Kernel Git Commit Log entry 00baeade and Kernel Git Commit Log entry 74d40852 for the full patch content.

Detection Methods for CVE-2026-98353

Indicators of Compromise

Kernel soft-lockup messages referencing erdma functions in dmesg or /var/log/messages
Unresponsive RDMA workloads with kernel threads stuck in XArray lock acquisition
Hung-task warnings naming erdma_create_qp, erdma_create_cq, or EQ interrupt handlers
Stack traces showing spin on xa_lock from hard IRQ context

Detection Strategies

Collect kernel crash dumps and run crash or drgn to inspect stuck CPUs for XArray lock contention within the erdma driver
Compare running kernel version and erdma module source against the fix commits referenced in the upstream advisory
Monitor telemetry pipelines for repeated hung-task or RCU stall events on hosts with eRDMA adapters

Monitoring Recommendations

Forward kern.log and dmesg output to a centralized log platform and alert on soft lockup, hung_task, and erdma keyword co-occurrence
Track kernel version inventory across hosts equipped with eRDMA NICs and flag unpatched builds
Baseline RDMA workload latency and alert on sustained stalls that may indicate the deadlock

How to Mitigate CVE-2026-98353

Immediate Actions Required

Identify Linux hosts using the erdma driver by checking lsmod | grep erdma and inventory their kernel versions
Apply the upstream stable kernel updates that incorporate the IRQ-safe XArray fix for erdma
Schedule reboots on affected systems after installing patched kernels, since the fix is in loadable driver code tightly bound to kernel internals

Patch Information

The fix converts QP and CQ create-path XArray updates, including the GSI QP store and error paths, to IRQ-safe helpers and initializes both arrays with XA_FLAGS_LOCK_IRQ. Patched kernels are available through the stable tree at commit 00baeade709fb66da647e8327e8398bb532e30f7 and commit 74d4085221a7ec5440996af199ccadfa75b9eb0e. Distribution vendors will backport the change into their supported kernels.

Workarounds

Unload the erdma module on systems that do not require RDMA until a patched kernel is deployed
Pin RDMA create and destroy operations away from CPUs handling erdma EQ interrupts using IRQ affinity tuning to reduce likelihood of the race
Avoid concurrent heavy QP/CQ creation under high interrupt load on unpatched hosts

bash

# Verify erdma driver presence and kernel version
uname -r
lsmod | grep erdma

# Temporary mitigation: unload the module if RDMA is not required
sudo modprobe -r erdma

# Prevent automatic load until patched
echo "blacklist erdma" | sudo tee /etc/modprobe.d/blacklist-erdma.conf