CVE-2026-90218: RDMA/cma: Fix WARNING in res_to_rt
In the Linux kernel, the following vulnerability has been resolved:
RDMA/cma: Fix WARNING in restort
syzbot reported a WARNON(!res->dev) in restort() triggered via addrhandler() during asynchronous address resolution:
" WARNING: drivers/infiniband/core/restrack.c:138 at restort+0x1c4/0x230 CPU#1: kworker/u8:4/59 Modules linked in: CPU: 1 UID: 0 PID: 59 Comm: kworker/u8:4 Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Compute Engine, BIOS Google 07/24/2026 Workqueue: ibaddr processonereq RIP: 0010:restort+0x1c4/0x230 drivers/infiniband/core/restrack.c:138 RSP: 0018:ffffc9000201f850 EFLAGS: 00010293 RAX: ffffffff88d00ce5 RBX: ffff88807f0fd4f8 RCX: ffff88801e6e0000 RDX: 0000000000000000 RSI: ffffffff8fd996f0 RDI: 0000000000000003 RBP: 0000000000000000 R08: ffff88801e6e0000 R09: 000000000000000a R10: 0000000000000009 R11: 0000000000000000 R12: dffffc0000000000 R13: 1ffff1100fe1fa9f R14: 0000000000000000 R15: 0000000000000003 FS: 0000000000000000(0000) GS:ffff888125012000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00001d559c3d2000 CR3: 0000000077c4c000 CR4: 00000000003526f0 Call Trace: <TASK> rdmarestrackadd+0x5a/0x8a0 drivers/infiniband/core/restrack.c:236 addrhandler+0x41a/0x5a0 drivers/infiniband/core/cma.c:3534 processonereq+0x2eb/0x540 drivers/infiniband/core/addr.c:624 processonework kernel/workqueue.c:3375 [inline] processscheduledworks+0xc4e/0x1630 kernel/workqueue.c:3458 workerthread+0xa47/0xfb0 kernel/workqueue.c:3539 kthread+0x388/0x470 kernel/kthread.c:436 retfromfork+0x514/0xb70 arch/x86/kernel/process.c:158 retfromforkasm+0x1a/0x30 arch/x86/entry/entry64.S:245 </TASK> "
In addrhandler(), cmaacquiredevbysrcip() is called to populate idpriv->cmadev and bind the associated ibdevice to idpriv->id.device. If cmaacquiredevbysrcip() returns an error (non-zero status), the ID remains unassociated with any RDMA device.
Previously, rdmarestrackadd(&idpriv->res) was invoked unconditionally even when cmaacquiredevbysrcip() failed, passing a resource with a NULL dev pointer and triggering the WARNON assertion in restort().
Fix this by only adding the resource to restrack when acquiring the device succeeds.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
In addr_handler(), call cma_acquire_dev_by_src_ip() to populate id_priv->cma_dev and only invoke rdma_restrack_add(&id_priv->res) when cma_acquire_dev_by_src_ip() returns success; do not add the resource to restrack if cma_acquire_dev_by_src_ip() fails (avoids passing a resource with a NULL id_priv->cma_dev into res_to_rt(), which triggers WARN_ON in drivers/infiniband/core/restrack.c:138).
Linux kernel RDMA/cma restrack rdma_restrack_add(&id_priv->res) invocation = only_add_when_acquire_succeeds
Event History
Frequently Asked Questions
What systems are realistically exposed to this issue?
The issue is in the Linux kernel RDMA connection manager path and is triggered during asynchronous address resolution. Systems that do not use this RDMA/cma functionality are not shown by the provided data to reach the affected path.
What evidence would indicate that a system has encountered the problem?
A kernel warning from res_to_rt(), specifically WARN_ON(!res->dev) at drivers/infiniband/core/restrack.c:138, is the reported symptom. The warning may appear from the ib_addr workqueue while processing asynchronous address-resolution requests.
Is there a documented mitigation if the kernel fix cannot be deployed immediately?
No mitigation or configuration workaround is provided. The available remediation information consists of the listed stable kernel commits.