VulnerabilityPublished 28 Oct 2026

CVE-2026-99212: Linux kernel · net/rds: don't let the rdma_cm destroy an id RDS still owns on route failure

Affects Linux kernelSource CVE Database V5

Not known to be exploited · fixed in a7c7d0ff876377fea7ae876a28d6df8d9349df57 : update Linux kernel when convenient.

Data as of 28 Oct 2026, 10:58 UTC

Severity

Unrated

Rated by Threat Radar · CVSS not yet scored by NVD

Patch: Available – fixed in a7c7d0ff876377fea7ae876a28d6df8d9349df57, 98d446b7c013254a8a7b49720557676a3a851fde, 91ece3efa064f0b3b3c67b9b045d9eeb4a034e43

Exploitation evidence

Disclosed: evidence found.
CVE published 28 Oct 2026
Detectable: no evidence on record.
No public nuclei template indexed
Weaponised: no evidence on record.
No public exploit code indexed in Metasploit or Exploit-DB
Exploited in the wildExploited: no evidence on record.
Not in CISA KEV and no source reports exploitation
Observed by OffSeq MirageSeen by Mirage: no evidence on record.
No attack traffic recorded by OffSeq Mirage sensors

A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 26 Oct 2026.

Disclosed: The CVE record is public on cve.org. Its publication is t = 0.
Detectable: A public nuclei template can find exposed instances, for defenders and attackers alike.
Weaponised: Public exploit code exists in Metasploit or Exploit-DB, or CISA SSVC or the CVSS exploit maturity reports a public proof of concept.
Exploited in the wild: CISA KEV lists it, CISA SSVC rates exploitation active, or a source reports attacks.
Observed by OffSeq Mirage: OffSeq Mirage honeypot sensors recorded attack traffic for this CVE, or found exposed hosts without attack traffic.

Moments are spaced evenly, not to scale; a dashed line marks a gap of six months or more. Deltas count from t = 0. Sources that give only a date (CISA KEV, Exploit-DB, or a time of exactly 00:00Z) read “same day” rather than hours. Metasploit modules carry the flaw’s disclosure date, not their release date, and nuclei templates carry no date, so both appear above but not on the timeline.

What to do

Upgrade Linux kernel to a7c7d0ff876377fea7ae876a28d6df8d9349df57, 98d446b7c013254a8a7b49720557676a3a851fde or 91ece3efa064f0b3b3c67b9b045d9eeb4a034e43.

Affected software

Product	Affected	Fixed in
LinuxLinux	Affected ≥ 55b7ed0b582f9ff4bf3b9b44969cddda8c6763ea, < a7c7d0ff876377fea7ae876a28d6df8d9349df57	Fixed in a7c7d0ff876377fea7ae876a28d6df8d9349df57
LinuxLinux	Affected ≥ 55b7ed0b582f9ff4bf3b9b44969cddda8c6763ea, < 98d446b7c013254a8a7b49720557676a3a851fde	Fixed in 98d446b7c013254a8a7b49720557676a3a851fde
LinuxLinux	Affected ≥ 55b7ed0b582f9ff4bf3b9b44969cddda8c6763ea, < 91ece3efa064f0b3b3c67b9b045d9eeb4a034e43	Fixed in 91ece3efa064f0b3b3c67b9b045d9eeb4a034e43
LinuxLinux	Affected =2.6.30	Fixed in–

Description

In the Linux kernel, the following vulnerability has been resolved: net/rds: don't let the rdma_cm destroy an id RDS still owns on route failure rds_rdma_cm_event_handler_cmn() hands the return value of rdma_resolve_route() straight back to the rdma_cm on RDMA_CM_EVENT_ADDR_RESOLVED. A synchronous failure there - -ENOMEM from the route work allocation, an SA query that cannot be set up, a RoCE route with no usable device - makes addr_handler() destroy the id the event was delivered on. That id is ic->i_cm_id, and nothing clears the pointer: the connection sits in RDS_CONN_CONNECTING with a freed id until its shutdown calls rdma_disconnect() and rdma_destroy_id() on it. The ROUTE_RESOLVED case already avoids this: rds_ib_cm_initiate_connect() forces a zero return while ic->i_cm_id == cm_id, as the comment there explains. Do the same here - drop the connection and return 0 - so the id stays RDS's to destroy from the shutdown, and the reconnect gets a fresh one.

References

Community reviews

Loading reviews…