Cloudanix VulnDB

CVE-2026-80864

None

CVSS

—

EPSS

0.2%

Published

Sep 4, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A bug in Linux RDMA networking code lets a local user crash the whole machine, causing temporary outages until the system is restarted.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
Moderate
Impact
Denial Of Service
Component
OS kernel
Class
Use After Free
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

Race in rxe_qp_from_attr() when setting IB_QP_MAX_DEST_RD_ATOMIC frees and reallocates resp.resources[] without holding state_lock while rxe_receiver() walks the array; free_rd_atomic_resources() also leaves qp->resp.res dangling, producing a slab use-after-free.

Why it matters to the business

Local denial-of-service on systems using Soft RoCE/RDMA; kernel panic or crash can interrupt workloads that rely on RDMA networking, requiring reboots and causing brief service outages.

How an attack unfolds

Local unprivileged user calls modify_qp() with only the MAX_DEST_RD_ATOMIC attribute; the call races against the live recv_task, swapping resources while rxe_prepare_res()/find_resource() dereference them, resulting in UAF inside rxe_receiver().

How to fix it

Apply the upstream fix that wraps the free/alloc sequence with rxe_disable_task()/rxe_enable_task() and clears qp->resp.res in free_rd_atomic_resources(); rebuild and boot the patched kernel.

How to confirm the fix worked

Confirm the patch is present by inspecting rxe_qp.c for the drain/enable sequence around rxe_qp_from_attr(); re-run the KASAN reproducer and verify absence of use-after-free reports in rxe_receiver().

Typical attack path

  1. Local process opens an RDMA device and obtains a QP
  2. Issue modify_qp() setting IB_QP_MAX_DEST_RD_ATOMIC outside any state transition
  3. free_rd_atomic_resources() runs concurrently with rxe_receiver() accesses
  4. Use-after-free triggers KASAN-detected slab corruption or kernel panic

How to detect it

Search kernel logs and KASAN reports for slab-use-after-free mentioning rxe_receiver(); inspect crash dumps for calls through rxe_qp_from_attr and free_rd_atomic_resources.

  • slab-use-after-free in rxe_receiver()
  • rxe_qp_from_attr
  • free_rd_atomic_resources
  • qp->resp.resources
  • rxe_prepare_res

What your security team should do

  • Patch kernels that enable CONFIG_RDMA_RXE within the next maintenance window
  • Restrict CAP_NET_RAW and RDMA device access for untrusted local users until patched
  • Add kernel crash and KASAN monitoring for rxe_receiver() signatures

The record

In the Linux kernel, the following vulnerability has been resolved: RDMA/rxe: Fix responder UAF on IB_QP_MAX_DEST_RD_ATOMIC modify_qp rxe_qp_from_attr() handles IB_QP_MAX_DEST_RD_ATOMIC outside the IB_QP_STATE path, so it holds no state_lock and runs while the responder task rxe_receiver() (recv_task on rxe_wq) is live. A modify_qp() setting only that attribute calls free_rd_atomic_resources() then alloc_rd_atomic_resources(), swapping qp->resp.resources[] while rxe_prepare_res()/find_resource() walk it; free_rd_atomic_resources() also leaves the cached pointer qp->resp.res dangling. A local unprivileged user can race the free/realloc into a use-after-free in rxe_receiver() (local DoS). Drain recv_task around the swap with rxe_disable_task()/rxe_enable_task(), as rxe_qp_reset() already does when tearing this array down, re-enabling only after alloc_rd_atomic_resources() succeeds so the responder never resumes against a NULL qp->resp.resources on the ENOMEM path. Also clear qp->resp.res in free_rd_atomic_resources(), like the rxe_resp.c completion paths. Reproduced under KASAN; the slab-use-after-free in rxe_receiver() is gone.

Affected packages

Ecosystem Package Introduced Fixed