CVE-2026-98353

Executive Summary

CVE-2026-98353 is a denial-of-service vulnerability in the Linux kernel RDMA subsystem, specifically the erdma driver, stemming from an unsafe lock-type mismatch between the QP/CQ create path and EQ-interrupt-driven lookups. When an event-queue (EQ) interrupt fires while a create path holds the plain (non-IRQ-safe) XArray lock, the interrupt handler spins indefinitely attempting to acquire the same lock, producing a hard deadlock. Any host running a kernel with the affected erdma driver and active RDMA workloads can be induced into a non-recoverable CPU spin (soft lockup/hard lockup) condition, degrading or halting the system.

Technical Analysis

The Linux kernel XArray data structure offers two families of locking helpers: plain variants (xa_lock, xa_store, etc.) that acquire a spinlock without disabling interrupts, and IRQ-safe variants that disable interrupts/local IRQ state while the lock is held. In the affected code, the QP (Queue Pair) and CQ (Completion Queue) tables are updated on the create path using the non-IRQ-safe helpers. The EQ interrupt path also performs locked QP and CQ lookups.

The deadlock condition is a classic lock-order / interrupt-context hazard:

1. A thread on a CPU enters a QP or CQ create path, takes the plain xa_lock for the table, and begins a modification (or a sleeping allocation within the locked region in paths where that is possible).
2. An EQ interrupt arrives (on the same CPU or a CPU contending for the same lock) and the interrupt handler attempts a locked QP/CQ lookup on that same table.
3. If the interrupt runs on the CPU that already holds the lock, the handler's acquisition attempt spins forever because the interrupted context cannot release the lock until the handler returns — a self-deadlock. If the interrupt runs on a different CPU, it spins waiting for the holder, and lock contention degrades into an extended spin.

The CNA description explicitly notes the problematic sites: "the create path holds the plain xa_lock … the lookup spins forever trying to acquire the same lock." It further instructs that "all QP and CQ create-path updates, including the GSI QP store and error paths" must use IRQ-safe helpers, and that both arrays should be initialized with XA_FLAGS_LOCK_IRQ so that sleeping allocations preserve interrupt state.

This is fundamentally a correctness/locking defect, not a memory-safety bug. The observable impact is a lockup (RCU stall / soft lockup / hard lockup reported by the kernel watchdog), not memory corruption. There is no evidence of privilege escalation, information disclosure, or code execution. No CVSS score or vector is assigned by NVD, and no CWE is supplied, though the mechanism maps cleanly to CWE-833 (Deadlock) and adjacent to CWE-662 (Improper Synchronization).

Exploitation Scenarios

No public PoC is available; the attack chain is inferred from the vulnerability class (deadlock via interrupt-context lock inversion) and the CNA description.

1. Reconnaissance / target identification. A local actor (or an entity able to drive RDMA operations) identifies a host with an RDMA-capable EDRMA NIC and the affected kernel driver loaded. Detection is trivial via local tooling enumerating RDMA devices and driver presence. No network exposure is required — this is a local / adjacent attack surface bound to RDMA verb activity.

2. Triggering the flaw class. The attacker drives concurrent RDMA control-plane activity: repeatedly creating Queue Pairs and Completion Queues (the "create-path" that takes the plain XArray lock) while event-queue interrupts (EQ interrupts performing locked QP/CQ lookups) fire. The race window is the interval during which the create path holds the non-IRQ-safe lock and the EQ interrupt handler contends for the same lock. Because the description states the lookup "spins forever trying to acquire the same lock," a successful interleaving yields a permanent spin rather than a transitory contention.

3. Execution method (vulnerability-class level). At the class level this is a denial-of-service through lock contention/interrupt-context inversion: the fault is triggered implicitly by the concurrency of legitimate-looking create operations and asynchronous interrupt delivery, not by an injected payload. No memory-safety primitive or privilege-boundary crossing is involved.

4. Post-exploitation impact. The impacted CPU spins, exhausting that core and generating kernel watchdog reports (soft lockup / hard lockup, RCU stall). Depending on the number of CPUs and lock scope, the host can become partially or fully unresponsive to RDMA and broader system workloads. Recovery typically requires reboot. There is no lateral movement, persistence, or data-exfiltration primitive associated with this defect.

Impact Assessment

• Confidentiality: None — the flaw does not disclose data.
• Integrity: None demonstrated — the lockup does not corrupt data.
• Availability: High — indefinite spin on the holding CPU, potential host-wide unresponsiveness, requiring reboot.
• Privilege required: Local / low-level actor with the ability to drive RDMA control-plane operations or cause the relevant create/interrupt interleaving; no remote pre-auth vector is described.
• Blast radius: Systems using the erdma driver with active RDMA workloads on the QP/CQ create path. Datacenter hosts, HPC nodes, and storage/RDMA-attached instances running affected kernels are the primary exposure. Because it is a kernel-level driver deadlock, a single trigger can take down an entire node's RDMA stack.

No CVSS score, vector, or EPSS value is available; CISA KEV status is NO, and no exploit code or nuclei template exists. Severity should be treated as an availability-impacting local DoS pending vendor scoring.

Detection Guidance

Sigma Rule

title: Linux Kernel Lockup Indicators Consistent with RDMA erdma QP/CQ Lock Inversion
id: 8b3c1e2a-rdma-erdma-lockup-cve-2026-98353
status: experimental
description: Detects kernel watchdog lockup signatures potentially caused by the RDMA erdma QP/CQ XArray lock inversion (CVE-2026-98353).
logsource:
  product: linux
  service: kernel
detection:
  selection_lockup:
    - "soft lockup"
    - "hard LOCKUP"
    - "watchdog: BUG: soft lockup"
    - "rcu_sched detected stall"
    - "RCU Stall"
  selection_erdma:
    - "erdma"
    - "RDMA/erdma"
  condition: selection_lockup and selection_erdma
falsepositives:
  - Other kernel lock contention unrelated to erdma
  - Intentional stress testing
level: high

YARA Rule

rule CVE_2026_98353_ERDMA_XARRAY_LOCK
{
    meta:
        description = "Detects erdma driver symbols/strings associated with unsafe XArray locking in the Linux kernel (CVE-2026-98353)"
        author = "Threat Intelligence"
        reference = "CVE-2026-98353"
        date = "2026-01-01"
    strings:
        $a = "erdma" nocase
        $b = "XA_FLAGS_LOCK_IRQ" ascii
        $c = "RDMA/erdma" ascii
        $d = "xa_lock" ascii
    condition:
        ($a and ($b or $c)) or ($c and $d)
}

Suricata IDS Rule

# No network vector is described for CVE-2026-98353 (kernel-local RDMA deadlock).
# The rule below alerts only on RDMA-related control traffic if captured, as a
# research/telemetry placeholder; it does not detect the lockup itself.
alert udp any any -> any any (msg:"RESEARCH Possible RDMA RoCE control traffic (CVE-2026-98353 context)"; app-layer-protocol:!unknown; dsize:>0; classtype:misc-activity; sid:202698353; rev:1;)

Elastic Detection

sequence by host.id with maxspan=5m
  [ process where event.category == "process" and process.name == "kworker/erdma" or process.command_line like "*erdma*" ]
  [ any where event.category == "host" and message like "*soft lockup*" or message like "*hard LOCKUP*" or message like "*RCU Stall*" ]

Splunk SPL Query

index=os_linux sourcetype=syslog ("soft lockup" OR "hard LOCKUP" OR "RCU Stall" OR "rcu_sched detected stall")
| search ("erdma" OR "RDMA/erdma")
| stats count min(_time) as first_seen max(_time) as last_seen by host
| where count > 0
| convert ctime(first_seen) ctime(last_seen)

Wazuh OSSEC Rule

<group name="linux,kernel,rdma,">
  <rule id="109853" level="12">
    <decoded_as>syslog</decoded_as>
    <match>soft lockup|hard LOCKUP|RCU Stall|rcu_sched detected stall</match>
    <regex>erdma|RDMA/erdma</regex>
    <description>CVE-2026-98353: Possible RDMA erdma QP/CQ XArray lock inversion lockup detected</description>
    <mitre>
      <id>T1499</id>
    </mitre>
  </rule>
</group>

Mitigation & Patch Guidance

Patch confidence: 0/4 (UNPATCHED — no patch evidence from any tracked source).

1. Immediate mitigations

   • Restrict local access to RDMA-capable devices to trusted, privileged operators only; the trigger requires driving QP/CQ create activity and/or inducing EQ interrupt timing.
   • Avoid sustained concurrent QP/CQ creation workloads on affected kernels until a fix is available.
   • Monitor kernel watchdog logs for soft/hard lockups and RCU stalls; treat erdma-correlated lockups as indicators and schedule reboots proactively.
   • Where feasible, temporarily unload or avoid enabling the erdma driver on nodes that do not require it.

2. Patch / upgrade steps

   • No vendor patch is confirmed by tracked sources (patch confidence 0/4). Apply the fix as described in the CNA advisory: convert all QP and CQ create-path updates — including the GSI QP store and error paths — to IRQ-safe XArray helpers, and initialize both arrays with XA_FLAGS_LOCK_IRQ so sleeping allocations preserve interrupt state.
   • Track the upstream Linux kernel RDMA/erdma tree for the corresponding commit and apply it via standard kernel update channels once released.

3. Long-term hardening

   • Adopt kernel builds with current locking best practices for interrupt-context-shared data structures (default to IRQ-safe locking where EQ handlers access the same tables).
   • Include RDMA driver concurrency and lockdep testing in CI/staging; enable lockdep on validation hosts to catch lock-order inversions before production.
   • Apply least-privilege controls over RDMA device access in multi-tenant environments.

References

• NVD — CVE-2026-98353: https://nvd.nist.gov/vuln/detail/CVE-2026-98353
• NVD Description (CNA) text for CVE-2026-98353 (Linux kernel RDMA/erdma XArray locking)
• Linux kernel RDMA subsystem / erdma driver upstream tree (patch reference to be confirmed upon release)
• CWE-833 Deadlock: https://cwe.mitre.org/data/definitions/833.html
• CISA KEV Catalog (CVE-2026-98353 not listed): https://www.cisa.gov/known-exploited-vulnerabilities-catalog

No known threat actor campaigns or exploit-in-the-wild evidence exist for CVE-2026-98353; the vulnerability is not in CISA KEV, has no public PoC, and has no assigned EPSS score.