Skip to main content
Vulnerability Database/CVE-2026-98366

CVE-2026-98366: Linux Kernel RDMA/rxe Use-After-Free Vulnerability

CVE-2026-98366 is a use-after-free flaw in Linux Kernel RDMA/rxe that occurs when validating access flags after swapping MR's PD, potentially causing memory corruption. This article covers technical details, impact, and mitigation.

Published:

CVE-2026-98366 Overview

CVE-2026-98366 is a use-after-free vulnerability in the Linux kernel's Soft RoCE (RDMA over Converged Ethernet) driver, specifically in the rxe_rereg_user_mr() function of the RDMA/rxe subsystem. The function reassigns the memory region's protection domain (mr->ibmr.pd) before validating the access flags passed by the caller. When validation fails after the PD swap, the kernel's reference counting becomes inconsistent, allowing the new PD to be freed while a memory window still references it. A local user with access to RDMA uverbs devices can trigger a kernel slab use-after-free, corrupting memory and potentially escalating privileges.

Critical Impact

Local attackers can trigger a kernel slab use-after-free in the RDMA/rxe driver, leading to memory corruption, denial of service, or potential local privilege escalation.

Affected Products

  • Linux kernel versions containing the RDMA/rxe Soft RoCE driver with the vulnerable rxe_rereg_user_mr() implementation
  • Distributions shipping the affected mainline kernel prior to the fix commits
  • Systems with the rdma_rxe kernel module loaded and uverbs device access exposed to local users

Discovery Timeline

  • 2026-10-06 - CVE-2026-98366 published to NVD
  • 2026-10-07 - Last updated in NVD database

Technical Details for CVE-2026-98366

Vulnerability Analysis

The flaw resides in rxe_rereg_user_mr() within the Soft RoCE driver. The function processes two flags from userspace, IB_MR_REREG_PD and IB_MR_REREG_ACCESS, but performs them in the wrong order. It first swaps mr->ibmr.pd to a new protection domain, then validates the requested access flags. When the access validation returns -EOPNOTSUPP, the PD reassignment is not reverted.

The InfiniBand core at ib_uverbs_rereg_mr() jumps to put_new_uobj on driver error without undoing the PD change. This leaves mr->pd == new_pd while the reference counts (usecnt) still charge the memory region to the original PD. A subsequent ib_dereg_mr_user() call then decrements the new PD's reference count, which can reach zero while an existing memory window still holds a reference to it.

When uverbs_free_pd() releases the PD based on that zero count, later cleanup via rxe_mw_cleanup() writes to the freed slab object. KASAN flags this as a slab use-after-free in __rxe_put().

Root Cause

The root cause is a validation-ordering defect [CWE-416 Use After Free]. State mutation precedes input validation, violating the atomic contract that the callback should either apply every requested change or none. Combined with the core layer's error path, which does not reverse driver-side state, this creates a reference-counting mismatch that enables premature deallocation of the protection domain object.

Attack Vector

Exploitation requires local access and the ability to open an RDMA uverbs device (typically /dev/infiniband/uverbs*). An attacker with these privileges issues a rereg_mr ioctl specifying both IB_MR_REREG_PD and IB_MR_REREG_ACCESS, supplying an unsupported access bit outside RXE_ACCESS_SUPPORTED_MR. The driver swaps the PD, then returns -EOPNOTSUPP, leaving refcounts inconsistent. Subsequent dealloc_pd and memory window cleanup operations trigger the use-after-free, yielding kernel memory corruption suitable for denial of service or privilege escalation.

No verified public exploit code is available. The upstream commit messages and KASAN report in the advisory describe the full crash path.

Detection Methods for CVE-2026-98366

Indicators of Compromise

  • KASAN reports showing slab-use-after-free in __rxe_put with call stacks containing rxe_mw_cleanup, __rxe_cleanup, and rxe_dealloc_mw
  • Kernel oops or panic entries referencing the rdma_rxe module following userspace calls to ib_uverbs_rereg_mr
  • Unexpected process terminations or RDMA subsystem errors on hosts where unprivileged users have access to InfiniBand uverbs devices

Detection Strategies

  • Enable KASAN on test and canary systems to surface use-after-free conditions in the rdma_rxe module during fuzzing or production triage
  • Audit which local users and containers have read/write access to /dev/infiniband/uverbs* character devices
  • Monitor kernel ring buffer output (dmesg) and journalctl -k for RDMA driver warnings, BUG reports, or references to rxe_rereg_user_mr

Monitoring Recommendations

  • Forward kernel logs to a centralized logging platform and alert on BUG:, KASAN, or rxe_ string matches
  • Track rdma_rxe module load events using auditd rules on /sbin/modprobe and /sys/module/rdma_rxe
  • Inventory hosts where the Soft RoCE driver is loaded but RDMA hardware is absent, as these are the most common targets for this class of flaw

How to Mitigate CVE-2026-98366

Immediate Actions Required

  • Apply the upstream kernel patches referenced in the advisory as soon as distribution builds are available
  • Unload the rdma_rxe module on systems that do not require Soft RoCE: modprobe -r rdma_rxe
  • Blacklist the module to prevent automatic loading by adding blacklist rdma_rxe to /etc/modprobe.d/
  • Restrict access to /dev/infiniband/uverbs* devices to trusted users and service accounts only

Patch Information

The fix validates the access flags before mutating any memory region state, ensuring the callback is atomic. Upstream fixes are available in the following kernel.org commits: 08f12745cb72, 4dd7a53f1c5b, 7230cc456d4b, ae36a5b609ae, and fe602c91a52e. Confirm your distribution has backported the fix before resuming use of the rdma_rxe module.

Workarounds

  • Disable Soft RoCE by unloading rdma_rxe where RDMA emulation is not required for workloads
  • Tighten permissions on InfiniBand uverbs device nodes using udev rules to limit access to a dedicated group
  • Isolate workloads that must use RDMA inside hardened containers or VMs with no untrusted local users
bash
# Configuration example: disable and blacklist the rdma_rxe module
sudo modprobe -r rdma_rxe
echo 'blacklist rdma_rxe' | sudo tee /etc/modprobe.d/disable-rxe.conf
sudo depmod -a

# Restrict uverbs device access to the rdma group
cat <<'EOF' | sudo tee /etc/udev/rules.d/90-rdma-uverbs.rules
KERNEL=="uverbs*", SUBSYSTEM=="infiniband_verbs", GROUP="rdma", MODE="0660"
EOF
sudo udevadm control --reload-rules && sudo udevadm trigger

Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

Experience the Most Advanced Cybersecurity Platform

See how the world’s most intelligent, autonomous cybersecurity platform can protect your organization today and into the future.