CVE-2026-98366: RDMA/rxe: validate access flags before swapping the MR's PD
In the Linux kernel, the following vulnerability has been resolved:
RDMA/rxe: validate access flags before swapping the MR's PD
rxereregusermr() reassigns mr->ibmr.pd first and only then validates the IBMRREREGACCESS argument:
if (flags & IBMRREREGPD) { rxeput(oldpd); rxeget(pd); mr->ibmr.pd = ibpd; }
if (flags & IBMRREREGACCESS) { if (access & ~RXEACCESSSUPPORTEDMR) return ERRPTR(-EOPNOTSUPP); mr->access = access; }
Both flags pass the entry check because RXEMRREREGSUPPORTED is IBMRREREGPD | IBMRREREGACCESS, 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: ibuverbsreregmr() jumps to putnewuobj on a driver error without undoing the reassignment, so mr->pd == newpd while the usecnts still charge the MR to origpd. ibderegmruser() then decrements newpd, whose count can reach zero while a memory window still references it; uverbsfreepd() frees the PD on that count alone and rxemwcleanup() writes to freed memory:
BUG: KASAN: slab-use-after-free in rxeput+0x31/0xa0 Write of size 4 at addr ffff8881301dd690 by task rxepoc/591 rxeput+0x31/0xa0 rxemwcleanup+0x42/0x200 rxecleanup+0x115/0x370 rxedeallocmw+0x4c/0x80 Allocated by task 591: ibuverbsallocpd+0x258/0x540 Freed by task 591: ibdeallocpduser+0x174/0x210 uverbsfreepd+0x8d/0xc0 ibuverbsdeallocpd+0x18e/0x1d0
Validate the access flags before mutating any state so the callback either applies every requested change or none.
Affected Software
Event History
Frequently Asked Questions
Who is exposed to this issue?
Systems using the Linux kernel's RDMA rxe component are exposed when memory-registration re-registration operations involving protection domains and access flags are performed. The issue concerns rxe memory regions and memory windows.
What does an attacker or triggering process need to do?
A caller must re-register an rxe user memory region with both protection-domain reassignment and access re-registration flags, while supplying unsupported access flags. This causes the protection domain to be reassigned before validation fails.
What happens when the vulnerable path is triggered?
The failed operation can leave the memory region associated with the new protection domain while usage counts remain charged to the original one. Later deregistration can reduce the new protection domain's count to zero and permit it to be freed while a memory window still references it, resulting in a slab use-after-free write.
How can administrators identify affected activity or failures?
A kernel report may show KASAN reporting a slab-use-after-free in __rxe_put, with rxe_mw_cleanup implicated. The triggering sequence involves a failed memory-region re-registration after a protection-domain change and unsupported access flags.