CVE-2026-90423 in Linux
Summary
by MITRE • 09/17/2026
In the Linux kernel, the following vulnerability has been resolved:
RDMA/rxe: Fix UAF in ODP init error-handling path
rxe_odp_mr_init_user() stores &umem_odp->umem in mr->umem before calling rxe_odp_init_pages(). If rxe_odp_init_pages() fails, rxe_odp_mr_init_user() releases umem_odp and returns an error.
rxe_reg_user_mr() then unwinds the error through rxe_cleanup(), rxe_mr_cleanup(), ib_umem_release(mr->umem). There is an IS_ERR_OR_NULL(umem) check at the start of ib_umem_release(). But since mr->umem is NOT reset to NULL in the error handling path of rxe_odp_mr_init_user(), the check passes and it reads already-freed fields like umem->is_dmabuf, causing UAF.
Fix the UAF by clearing mr->umem after releasing the failed ODP umem so the MR cleanup path does not release it again.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 09/17/2026
The Linux kernel's RDMA/rxe subsystem contains a use-after-free vulnerability within its On-Demand Paging initialization error-handling logic, specifically in the rxe_odp_mr_init_user function. This flaw arises from an improper management of memory region state during failure scenarios. When initializing user memory for on-demand paging, the driver assigns a pointer to the umem structure into mr->umem before attempting to initialize pages via rxe_odp_init_pages. If this initialization fails and returns an error code, the function correctly releases the allocated umem_odp resources to prevent resource leaks. However, it neglects to reset the mr->umem pointer to NULL after performing this release operation. This oversight leaves a dangling pointer in the memory region structure that still references freed kernel memory.
The operational impact of this vulnerability manifests when the error handling path propagates upward through rxe_reg_user_mr and eventually triggers cleanup routines such as rxe_cleanup and rxe_mr_cleanup. These functions invoke ib_umem_release to finalize the destruction of the memory region. Although ib_umem_release includes a safety check using IS_ERR_OR_NULL to verify if umem is valid before proceeding, this check only validates whether the pointer itself is an error code or null. Since mr->umem was not cleared and still holds the address of the previously freed object, the condition passes erroneously. Consequently, ib_umem_release proceeds to dereference fields within the now-deallocated memory structure, such as umem->is_dmabuf. Accessing these invalid memory locations constitutes a classic use-after-free vulnerability, which can lead to kernel crashes, data corruption, or potentially arbitrary code execution depending on how the freed memory is reallocated and accessed by other subsystems.
From a classification perspective, this issue aligns with CWE-416, Use After Free, where software continues to use a pointer after it has been freed. The vulnerability also relates to improper resource cleanup practices often associated with CWE-755: Improper Handling of Exceptional Conditions. In the context of the MITRE ATT&CK framework for Linux systems, this type of memory corruption flaw can be leveraged in techniques related to privilege escalation or defense evasion if an attacker can trigger the specific error condition that leads to the use-after-free state. The lack of pointer nullification represents a fundamental failure in maintaining object lifecycle integrity during exceptional control flow paths.
To mitigate this vulnerability and prevent similar issues, developers must ensure that all pointers referencing dynamically allocated resources are explicitly set to NULL immediately after those resources are freed or released. This practice ensures that subsequent cleanup routines perform accurate validity checks before attempting to access memory fields. In the specific case of rxe_odp_mr_init_user, the fix involves clearing mr->umem to NULL right after calling the release function for umem_odp in the error path. Additionally, robust defensive programming strategies should include adding explicit null checks or using helper macros that verify pointer validity before any dereference operations occur during cleanup sequences. Regular static analysis and code reviews focusing on error-handling paths are essential to identify such logical flaws where state consistency is compromised due to incomplete variable updates upon failure conditions.