Description

In the Linux kernel, the following vulnerability has been resolved: RDMA/rxe: validate access flags before swapping the MR's PD rxe_rereg_user_mr() reassigns mr->ibmr.pd first and only then validates the IB_MR_REREG_ACCESS argument: if (flags & IB_MR_REREG_PD) { rxe_put(old_pd); rxe_get(pd); mr->ibmr.pd = ibpd; } if (flags & IB_MR_REREG_ACCESS) { if (access & ~RXE_ACCESS_SUPPORTED_MR) return ERR_PTR(-EOPNOTSUPP); mr->access = access; } Both flags pass the entry check because RXE_MR_REREG_SUPPORTED is IB_MR_REREG_PD | IB_MR_REREG_ACCESS, so a caller can reach the access check with mr->ibmr.pd already reassigned. mr->ibmr.pd is owned by the core, which adjusts pd->usecnt only on the success path: ib_uverbs_rereg_mr() jumps to put_new_uobj on a driver error without undoing the reassignment, so mr->pd == new_pd while the usecnts still charge the MR to orig_pd. ib_dereg_mr_user() then decrements new_pd, whose count can reach zero while a memory window still references it; uverbs_free_pd() frees the PD on that count alone and rxe_mw_cleanup() writes to freed memory: BUG: KASAN: slab-use-after-free in __rxe_put+0x31/0xa0 Write of size 4 at addr ffff8881301dd690 by task rxe_poc/591 __rxe_put+0x31/0xa0 rxe_mw_cleanup+0x42/0x200 __rxe_cleanup+0x115/0x370 rxe_dealloc_mw+0x4c/0x80 Allocated by task 591: ib_uverbs_alloc_pd+0x258/0x540 Freed by task 591: ib_dealloc_pd_user+0x174/0x210 uverbs_free_pd+0x8d/0xc0 ib_uverbs_dealloc_pd+0x18e/0x1d0 Validate the access flags before mutating any state so the callback either applies every requested change or none.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.8",
  "pubDate": "2026-10-06T09:18:30.823Z",
  "pubdate": "2026-10-06T09:18:30.823Z",
  "executiveSummary": "A use-after-free vulnerability exists in the Linux kernel's RDMA/rxe implementation during the re-registration of memory regions.\nThe flaw originates from an improper order of operations within the rxe_rereg_user_mr function, where internal state is modified before input validation occurs.\nIf the access flag validation fails after the Protection Domain (PD) has already been reassigned, the kernel fails to rollback the state, leading to inconsistent reference counting on the associated PD objects.\nThis inconsistency allows an attacker to trigger a premature free of a Protection Domain that is still in use by memory windows, resulting in a use-after-free condition during subsequent cleanup routines.\nSuccessful exploitation of this vulnerability could lead to kernel memory corruption, arbitrary code execution, or local denial of service via a kernel panic.\nThe vulnerability affects systems utilizing the RDMA/rxe software stack. Exploitation typically requires local user access with the ability to initiate RDMA verbs operations.",
  "technicalDetails": "The root cause of this vulnerability is a lack of atomicity and state consistency in the rxe_rereg_user_mr() function within the RDMA/rxe (soft-RoCE) driver. Specifically, the function modifies the mr->ibmr.pd pointer to point to a new Protection Domain (PD) before verifying if the subsequent IB_MR_REREG_ACCESS flags are valid.\nWhen a user calls to re-register a memory region with invalid access flags, the function performs the reassignment of the PD and then proceeds to validate the access flags. Upon encountering an invalid flag, the function returns an error (EOPNOTSUPP) without reverting the mr->ibmr.pd pointer back to its original state.\nBecause the core RDMA subsystem manages PD reference counts (usecnt) based on the successful completion of the re-registration process, the failure within the driver leaves the kernel in an inconsistent state: the mr->ibmr.pd points to the 'new_pd', but the 'orig_pd' is still being tracked by the core as being in use by the MR. Conversely, the 'new_pd' object's usage count does not accurately reflect the active references from the memory region.\nThe attack flow proceeds as follows: 1) An attacker requests a memory region re-registration with a valid IB_MR_REREG_PD flag but an invalid IB_MR_REREG_ACCESS flag. 2) The driver updates the MR's PD reference. 3) The driver returns an error code due to the invalid access flags. 4) The core RDMA stack, assuming no changes occurred, does not perform cleanup on the 'new_pd'. 5) Upon application exit or resource de-allocation, the system attempts to free the 'new_pd', causing its reference count to drop to zero while a Memory Window (MW) still holds a reference to it.\nThe final stage involves the triggering of rxe_mw_cleanup() during a subsequent de-allocation operation. Because the PD has already been freed, the system performs a write or read operation on the stale, deallocated memory address (KASAN: slab-use-after-free).\nThis vulnerability is particularly dangerous because it corrupts internal kernel object references, leading to non-deterministic crashes or the potential for privilege escalation if the freed slab memory is reallocated by a different, sensitive kernel structure before the use-after-free occurs. The vulnerability is local and does not require complex remote network traffic beyond the initiation of the RDMA verbs API."
}