CVE-2026-80864 Overview
CVE-2026-80864 is a use-after-free vulnerability in the Linux kernel's Soft RoCE (rxe) RDMA driver. The flaw resides in rxe_qp_from_attr(), which handles the IB_QP_MAX_DEST_RD_ATOMIC attribute outside the IB_QP_STATE path. Because no state_lock is held during this operation, the responder task rxe_receiver() continues to run against the queue pair's resource array while a concurrent modify_qp() frees and reallocates it. A local unprivileged user can race the free and reallocation to trigger a slab use-after-free in the responder.
Critical Impact
A local unprivileged attacker can trigger a use-after-free in the kernel RDMA responder, causing a denial of service and potentially exposing further kernel exploitation primitives.
Affected Products
- Linux kernel versions containing the RDMA/rxe Soft RoCE driver prior to the fixing commits
- Distributions shipping vulnerable stable kernel branches referenced by the upstream fixes
- Systems with the rdma_rxe kernel module loaded and accessible to unprivileged users
Discovery Timeline
- 2026-09-04 - CVE-2026-80864 published to NVD
- 2026-09-04 - Last updated in NVD database
Technical Details for CVE-2026-80864
Vulnerability Analysis
The vulnerability affects the Linux kernel's Soft RoCE driver, which implements RDMA over Converged Ethernet in software. The queue pair (QP) modification routine rxe_qp_from_attr() processes the IB_QP_MAX_DEST_RD_ATOMIC attribute on a separate code path from the standard IB_QP_STATE transition. That separate path does not acquire state_lock and does not synchronize with the responder work item rxe_receiver() (recv_task on rxe_wq).
When a caller issues modify_qp() setting only IB_QP_MAX_DEST_RD_ATOMIC, the driver invokes free_rd_atomic_resources() followed by alloc_rd_atomic_resources(). This swaps the qp->resp.resources[] array while rxe_prepare_res() and find_resource() are still walking it from the responder context. The free path also leaves the cached pointer qp->resp.res dangling, compounding the window for corruption.
Root Cause
The root cause is missing synchronization between the QP attribute modification path and the responder work queue. The IB_QP_MAX_DEST_RD_ATOMIC handler mutates shared responder state without draining the responder task or holding a lock that the responder respects. Additionally, free_rd_atomic_resources() does not clear qp->resp.res, so a stale pointer to freed memory remains reachable through the responder's completion paths.
Attack Vector
A local unprivileged user with the ability to open an rxe RDMA device can issue crafted modify_qp() calls that toggle IB_QP_MAX_DEST_RD_ATOMIC while the responder is active. Racing the free and reallocation against rxe_receiver() produces a slab use-after-free, reproducible under KASAN. Exploitation requires local access but no elevated privileges. The immediate consequence is a local denial of service through kernel corruption; use-after-free primitives in kernel memory can, depending on the slab layout, be leveraged toward further impact.
The upstream fix drains recv_task around the resource swap by calling rxe_disable_task() before free_rd_atomic_resources() and rxe_enable_task() only after alloc_rd_atomic_resources() succeeds. This mirrors the tear-down pattern in rxe_qp_reset(). The fix also clears qp->resp.res inside free_rd_atomic_resources(), matching the pattern used in the rxe_resp.c completion paths. See the upstream patches for full details: Kernel Patch Commit 0136b528 and Kernel Patch Commit 6f701423.
Detection Methods for CVE-2026-80864
Indicators of Compromise
- KASAN reports of slab-use-after-free originating in rxe_receiver(), rxe_prepare_res(), or find_resource().
- Kernel oops or general protection fault traces referencing qp->resp.resources or qp->resp.res on systems with the rdma_rxe module loaded.
- Unexpected modify_qp ioctl activity from unprivileged processes targeting Soft RoCE devices.
Detection Strategies
- Enable KASAN on test and staging kernels to catch use-after-free access patterns in the rxe responder path.
- Audit which local users and containers have access to /dev/infiniband/* and RDMA verbs interfaces; unexpected access is a strong signal.
- Monitor kernel ring buffer output for rxe-related warnings, BUG reports, or list corruption messages.
Monitoring Recommendations
- Collect kernel logs centrally and alert on KASAN, BUG:, and general protection fault entries referencing rxe_ symbols.
- Track loaded kernel modules across the fleet and flag hosts where rdma_rxe is loaded without an operational requirement.
- Baseline the set of processes issuing RDMA verbs syscalls and investigate deviations, particularly from unprivileged accounts.
How to Mitigate CVE-2026-80864
Immediate Actions Required
- Apply the upstream stable kernel updates that include the referenced fixing commits to all Linux systems running the rxe driver.
- If patching is not immediately feasible, unload and blacklist the rdma_rxe module on hosts that do not require Soft RoCE.
- Restrict access to RDMA device nodes so that only trusted service accounts can open Soft RoCE queue pairs.
Patch Information
The fix is distributed across multiple stable branches. Relevant upstream commits include Kernel Patch Commit 0136b528, Kernel Patch Commit 60dfd479, Kernel Patch Commit 6f701423, Kernel Patch Commit d4cd32eb, and Kernel Patch Commit ffa4f0be. The fix drains the responder task around the free_rd_atomic_resources() and alloc_rd_atomic_resources() sequence and clears the cached qp->resp.res pointer to prevent dangling references.
Workarounds
- Blacklist the rdma_rxe module on systems that do not use Soft RoCE, preventing the vulnerable code path from being reachable.
- Remove unprivileged user access to /dev/infiniband/* device nodes using restrictive udev rules and group ownership.
- Constrain container workloads with seccomp and device cgroup policies that block access to RDMA verbs interfaces.
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.
