Cloudanix VulnDB

CVE-2026-98352

None

CVSS

—

EPSS

0.2%

Published

Oct 6, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A timing flaw in the Linux kernel's high-speed networking code can leave resources behind when connections are interrupted, which may cause warnings or instability when hardware is removed.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
Moderate
Impact
Denial Of Service
Component
OS kernel
Class
Race Condition
Remediation
Patch
Effort
Medium
Patch risk
Low

What it actually does

Race condition in RDMA client connection teardown allows ADDR_RESOLVED handler to borrow CQ credits after destroy path has begun, leaving a CQ reference that triggers WARN_ON during later device unregister cleanup.

Why it matters to the business

Systems using RDMA over fabrics may experience kernel warnings, resource leaks, or instability during connection failures or module unload, increasing operational risk for high-performance storage and networking workloads.

How an attack unfolds

An attacker with local access triggers repeated RDMA connection attempts that are interrupted via signals or timeouts; the race between the ADDR_RESOLVED handler and destroy_con_cq_qp under con_mutex allows a CQ to be referenced after the connection object is freed, surfacing only on subsequent device cleanup.

How to fix it

Update to a Linux kernel containing the referenced fix that sets a per-connection flag under con_mutex before CQ/QP teardown to prevent racing credit acquisition.

How to confirm the fix worked

Confirm the patch is applied by inspecting the RDMA/rtrs-clt source for the new flag check before ib_cq_pool_get in ADDR_RESOLVED; re-test interrupted connect paths and verify absence of WARN_ON during device unregister.

Typical attack path

  1. Obtain local access on a system with RDMA/rtrs-clt in use
  2. Trigger rapid connect attempts that hit wait_event_interruptible_timeout returning -ERESTARTSYS
  3. Force concurrent teardown via module unload or device removal while handler still holds con_mutex
  4. Observe CQ reference leak and subsequent WARN_ON(cq->cqe_used) on ib_cq_pool_cleanup

How to detect it

Search kernel logs for WARN_ON messages referencing ib_cq_pool_cleanup or cq->cqe_used during RDMA device removal; correlate with rtrs-clt connection failures or interrupted RDMA_CM events.

What your security team should do

  • Prioritize kernel updates on any hosts exposing RDMA interfaces
  • Monitor for RDMA-related kernel warnings in production logs
  • Limit unprivileged local access on systems using RDMA fabrics until patched

The record

In the Linux kernel, the following vulnerability has been resolved: RDMA/rtrs-clt: Fix CQ pool leak when connect is interrupted The client borrows shared CQ credits in the ADDR_RESOLVED handler via ib_cq_pool_get(), before the peer is connected. create_cm() can return -ERESTARTSYS from wait_event_interruptible_timeout() without destroying the CM ID. The init_conns() and stop-and-destroy paths then call destroy_con_cq_qp() while cq is still NULL (no PUT) and only afterwards rdma_destroy_id(). CMA serializes the handler against rdma_destroy_id() with handler_mutex, but that does not order the GET against destroy_con_cq_qp(). If ADDR_RESOLVED has already passed the DESTROYING check, it can take con_mutex, GET credits, and then lose the con to kfree. Device unregister later hits WARN_ON(cq->cqe_used) in ib_cq_pool_cleanup(). Set a per-connection flag under con_mutex before CQ/QP teardown so a racing ADDR_RESOLVED cannot borrow credits after teardown has begun.

Affected packages

Ecosystem Package Introduced Fixed