kernel/linux.git/drivers/infiniband/core, branch v7.1.7

RDMA/core: Fix memory leak in __ib_create_cq() on invalid cqe

2026-08-03T09:25:17+00:00

[ Upstream commit e939334ea7dd219f100f963dbb1cb43df520c20a ] Move the zero CQE validation before rdma_zalloc_drv_obj() to avoid leaking the CQ object when returning -EINVAL. Fixes: a2917582887a ("RDMA/core: Reject zero CQE count") Link: https://patch.msgid.link/r/20260625020148.224537-1-zhaochenguang@kylinos.cn Signed-off-by: Chenguang Zhao Reviewed-by: Kalesh AP Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin

RDMA/cma: Fix hardware address comparison length in netevent callback

2026-08-03T09:25:17+00:00

[ Upstream commit 18313833e2c6de222a4f6c072da759d0d5888528 ] The cited commit hardcoded the hardware address comparison len to ETH_ALEN. This breaks IPoIB, which uses 20-byte addresses. By truncating the memcmp, the CMA may incorrectly assume the target address is unchanged and fails to abort the stalled connection. Fix this by replacing ETH_ALEN with the dynamic neigh->dev->addr_len to correctly evaluate the full address regardless of the link layer. Fixes: 925d046e7e52 ("RDMA/core: Add a netevent notifier to cma") Signed-off-by: Or Gerlitz Link: https://patch.msgid.link/20260617-fix-cma-ipoib-v1-1-03f869344304@ddn.com Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin

IB/mad: Drop unmatched RMPP responses before reassembly

2026-08-03T09:25:16+00:00

[ Upstream commit d2e52d610b9b09694261632340b801a421e0b0c5 ] Kernel-handled RMPP receive processing starts reassembly for active DATA responses before the response is matched to an outstanding send. The normal match happens later, after ib_process_rmpp_recv_wc() has either assembled a complete message or consumed the segment. That ordering lets an unsolicited response that routes to a kernel RMPP agent by the high TID bits allocate or extend RMPP receive state before the full TID and source address are checked against a real request. A reordered burst can therefore reach the receive-side insertion path even though the response would not match any send. For kernel-handled RMPP DATA responses, require the existing ib_find_send_mad() match before entering RMPP reassembly. The matcher already checks the full TID, management class and source address/GID against the agent wait, backlog and in-flight send lists. If there is no match, drop the response without creating RMPP state. This leaves the RMPP window behavior unchanged and only rejects responses that have no corresponding request. Fixes: fa619a77046b ("[PATCH] IB: Add RMPP implementation") Assisted-by: Codex:gpt-5-5-xhigh Signed-off-by: Michael Bommarito Link: https://patch.msgid.link/3170ff3bc389a930bb1641f2caa394a0b2241579.1780774907.git.michael.bommarito@gmail.com Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin

RDMA/core: Add ib_frmr_pool_drop for unrecoverable handles

2026-07-24T14:19:48+00:00

[ Upstream commit ddbc251be18fb82884ee6e9af634cc9f1171a4d6 ] A driver that has popped a handle from an FRMR pool can hit failures that leave the handle in a state where it can't safely be returned for reuse. The driver destroys the handle itself, but the pool has no way to learn about it, so the in_use counter drifts upward. Add ib_frmr_pool_drop to balance the pool's accounting in this case. Every pop is now balanced by exactly one push or drop. Fixes: 36680ef7bceb ("RDMA/mlx5: Switch from MR cache to FRMR pools") Link: https://patch.msgid.link/r/20260610000145.820592-9-michaelgur@nvidia.com Signed-off-by: Michael Guralnik Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin

RDMA/core: Fix FRMR handle leak on push failure

2026-07-24T14:19:48+00:00

[ Upstream commit 8c76126b866649d8e8acc09a06f2b03b6ff88900 ] Failure to push a handle to the pool, caused by ENOMEM on queue page allocation, will trigger missing in_use counter update, skewing pool state indefinitely. Fix that by moving the handling of handle destruction in such case into the FRMR code, ensuring the handle is either pushed to the pool or destroyed inside the same function. Adjust mlx5_ib call site accordingly. Fixes: ce5df0b891ed ("IB/core: Introduce FRMR pools") Link: https://patch.msgid.link/r/20260610000145.820592-8-michaelgur@nvidia.com Signed-off-by: Michael Guralnik Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin

RDMA/core: Avoid NULL dereference on FRMR bad usage

2026-07-24T14:19:48+00:00

[ Upstream commit 3937243095b5cfed6556bd1ea170790223f3eeb0 ] In case a driver calls FRMR pop operation without a successful init, return after triggering a warning to avoid the NULL dereference. Fixes: ce5df0b891ed ("IB/core: Introduce FRMR pools") Link: https://patch.msgid.link/r/20260610000145.820592-7-michaelgur@nvidia.com Signed-off-by: Michael Guralnik Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin

RDMA/core: Fix FRMR set pinned push error path

2026-07-24T14:19:47+00:00

[ Upstream commit 41a707d0275cdec9ac125e826dd6836fa9623cbc ] Add destruction of FRMR handles in case the push to the pool fails. This prevents resources leak in case pool page allocation fails. Fixes: 020d189d16a6 ("RDMA/core: Add pinned handles to FRMR pools") Link: https://patch.msgid.link/r/20260610000145.820592-6-michaelgur@nvidia.com Signed-off-by: Michael Guralnik Reviewed-by: Tao Cui Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin

RDMA/core: Fix FRMR aging push to queue error flow

2026-07-24T14:19:47+00:00

[ Upstream commit c6936506ed556ce3ccad36ab999baf2764dd7d25 ] Aging pools with pinned handles requires moving handles from the active queue to a non-empty inactive queue that might fail on new page allocation, we are currently not handling the fault and leaking any mkey that fails the push. Fix by Introducing push_queue_to_queue_locked() that fills the destination's partial tail page from the source and then splices the remaining source pages onto the destination, performing no allocation. Replace the per-handle move loop in age_pinned_pool() and the open-coded splice in pool_aging_work() with calls to the helper. As the helper cannot fail under memory pressure, removing a class of GFP_ATOMIC allocations under the pool lock and simplifying the error flow. Fixes: 020d189d16a6 ("RDMA/core: Add pinned handles to FRMR pools") Link: https://patch.msgid.link/r/20260610000145.820592-5-michaelgur@nvidia.com Signed-off-by: Michael Guralnik Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin

RDMA/core: Fix skipped usage for driver built FRMR key

2026-07-24T14:19:47+00:00

[ Upstream commit 3d7fd88aeff73f25ee740b3a65a3b4dd38ad7783 ] When creating FRMR handles following a netlink command to pin handles, use the key after driver callback instead of using the key passed directly from user. Fixes: 020d189d16a6 ("RDMA/core: Add pinned handles to FRMR pools") Link: https://patch.msgid.link/r/20260610000145.820592-4-michaelgur@nvidia.com Signed-off-by: Michael Guralnik Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin

RDMA/nldev: Fix locking when accessing mr->pd

2026-07-24T14:19:37+00:00

[ Upstream commit 50d5c02ab8e62325548bd3a6e6b758a9dcd6e7c3 ] Sashiko points out that, due to rereg_mr, the PD is actually variable and all the touches in nldev are racy. Use mr->device instead of mr->pd->device. Getting the PD restrack ID is more tricky. To avoid disturbing all the happy paths, add an rdma_restrack_sync() operation which is sort of like flush_workqueue() or synchronize_irq(): after it returns, all the old nldev touches to the mr are gone and everything sees the new PD. This makes it safe to reach into the PD pointer. Fixes: da5c85078215 ("RDMA/nldev: add driver-specific resource tracking") Link: https://patch.msgid.link/r/4-v1-29ebd2c229b5+fd5-ib_mr_pd_jgg@nvidia.com Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin