Cloudanix VulnDB

CVE-2026-90423

High · 7.8

CVSS

7.8

EPSS

0.2%

Published

Sep 17, 2026

CISA due date

—

Cloudanix analysis

Next patch cycle SSVC: Track

A bug in Linux kernel code that handles fast network memory transfers can let nearby users crash the machine or possibly take over the system.

Exploitation
Local Privilege
Attacker needs
Low Privilege
Complexity
Low
Impact
Full Compromise
Component
OS kernel
Class
Use After Free
Remediation
Patch
Effort
Low
Patch risk
Low

What it actually does

Use-after-free in RDMA/rxe ODP error path: rxe_odp_mr_init_user frees umem_odp on rxe_odp_init_pages failure but leaves mr->umem pointing to the freed object; later ib_umem_release in rxe_mr_cleanup passes the IS_ERR_OR_NULL check and dereferences freed fields such as is_dmabuf.

Why it matters to the business

Local users on Linux systems using RDMA (RoCE, iWARP, InfiniBand) can trigger kernel crashes or memory corruption, leading to denial of service or potential privilege escalation in HPC, storage, and low-latency networking environments.

How an attack unfolds

An attacker with local access loads the rxe module, registers a user MR that exercises the ODP path, forces rxe_odp_init_pages to fail, then relies on the subsequent cleanup in rxe_reg_user_mr to dereference the dangling mr->umem pointer.

How to fix it

Apply the upstream fix that sets mr->umem = NULL immediately after releasing the failed ODP umem in rxe_odp_mr_init_user; rebuild and reboot to the patched kernel.

How to confirm the fix worked

Inspect the patched rxe_odp_mr_init_user function to confirm mr->umem is cleared on the error path; run targeted regression tests that exercise ODP MR registration failure followed by cleanup.

Typical attack path

  1. Obtain local unprivileged shell on affected kernel
  2. Ensure rxe RDMA driver is loaded and ODP is enabled
  3. Issue ibv_reg_mr or equivalent that reaches rxe_odp_mr_init_user
  4. Induce failure in rxe_odp_init_pages (e.g., memory pressure or invalid parameters)
  5. Trigger rxe_cleanup / rxe_mr_cleanup to perform the second release
  6. Read or write through the freed umem object for crash or exploitation

How to detect it

Search kernel logs and crash dumps for rxe_odp_mr_init_user, rxe_mr_cleanup, or ib_umem_release call stacks containing use-after-free or slab-out-of-bounds reports; correlate with processes performing RDMA MR registration.

What your security team should do

  • Prioritize kernel update on all systems exposing RDMA interfaces
  • Temporarily disable rxe or ODP if patching cannot be performed quickly
  • Add kernel memory-safety monitoring (KASAN, KFENCE) in staging environments
  • Review RDMA user permissions and limit CAP_NET_RAW / CAP_SYS_ADMIN where possible

The record

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.

Affected packages

Ecosystem Package Introduced Fixed