CVE-2026-98352

Description

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.

Is your site exposed to CVE-2026-98352?

Run a free security scan — no signup, results in seconds.

EPSS — Exploit Prediction

0.0017

Probability of exploitation

0.05%

Percentile rank

EPSS estimates the probability that this vulnerability will be exploited in the wild within the next 30 days. A higher score means more likely to be exploited.

References

Other References

https://git.kernel.org/stable/c/2ae16aaa78b5edc6e6d0904c84fd9cdfb762bcda https://git.kernel.org/stable/c/31024e158b45358370a0a14ed96589e6aa62d6cb https://git.kernel.org/stable/c/6f8020fe7465f49e234a576c04e415e9d08c7878 https://git.kernel.org/stable/c/74c4ed55e61f1b65ddbebc5b635d136461a1c3da https://git.kernel.org/stable/c/8f253d5893f991742464b9e7203c43fc08d0aa11 https://git.kernel.org/stable/c/a82cca40139d9fcae8208901856bd5bb4051f097 https://git.kernel.org/stable/c/bf88ac4867050112a6c819c8d1a7209bf48ef427

Frequently Asked Questions

What is CVE-2026-98352? +

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.

How do I check if I'm vulnerable to CVE-2026-98352? +

You can use Secably's free Website Scanner to check your website for known vulnerabilities. For infrastructure scanning, use the Port Scanner to identify exposed services that may be affected. Check the vendor advisories linked above for specific patch and version information.