Cloudanix VulnDB

CVE-2026-98360

High · 7.0

CVSS

7.0

EPSS

0.1%

Published

Oct 6, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A memory-handling mistake in the Linux kernel's RDMA multicast code can let a local user crash the system or potentially gain elevated access under rare network-device conditions.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
High
Impact
Privilege Gain
Component
OS kernel
Class
Use After Free
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

Use-after-free in RDMA/rxe multicast group handling: rxe_get_mcg publishes a struct rxe_mcg to the mcg_tree before rxe_mcast_add() succeeds; on error the object is freed while still reachable, so a subsequent __rxe_lookup_mcg() dereferences the freed memory.

Why it matters to the business

Local denial-of-service or potential privilege escalation on systems exposing RDMA/rxe to untrusted userspace clients; low prevalence and high attack complexity limit widespread impact, but kernel crashes or memory corruption remain possible until patched.

How an attack unfolds

A local userspace process issues ATTACH_MCAST on a UD QP while rxe_mcast_add() is forced to fail (e.g., backing netdev removed); the resulting freed mcg is later looked up, producing a slab use-after-free that an attacker with local RDMA access can attempt to exploit for code execution or crash.

How to fix it

Upgrade the Linux kernel to a version containing the fix that moves tree publication into __rxe_publish_mcg() after rxe_mcast_add() succeeds; rebuild and reboot with the updated kernel package.

How to confirm the fix worked

Confirm the running kernel contains the commit that splits publication and calls rxe_mcast_add() before tree insertion; reproduce the original failure path under KASAN to verify absence of slab-use-after-free reports.

Typical attack path

  1. Obtain local unprivileged access on a host with the rxe RDMA driver loaded
  2. Create a UD QP and issue ATTACH_MCAST for an MGID while inducing rxe_mcast_add() failure
  3. Trigger a subsequent lookup of the same MGID to dereference the freed mcg object

How to detect it

Inspect kernel logs and KASAN reports for slab-use-after-free mentions involving __rxe_lookup_mcg or rxe_mcg structures; correlate with RDMA ATTACH_MCAST activity on rxe devices.

What your security team should do

  • Prioritize kernel updates on any host exposing RDMA/rxe interfaces
  • Restrict unprivileged access to RDMA device nodes via cgroups or LSM policy where feasible
  • Monitor kernel update channels for the stable backport of the rxe_mcg fix

The record

In the Linux kernel, the following vulnerability has been resolved: RDMA/rxe: insert mcg into mcg_tree only after rxe_mcast_add() succeeds rxe_get_mcg() publishes a newly allocated multicast group in rxe->mcg_tree before programming the backing Ethernet multicast address with rxe_mcast_add(), which runs outside mcg_lock. A local userspace RDMA client reaches this path with ATTACH_MCAST on a UD QP; if rxe_mcast_add() then returns an error (for example -ENODEV when the backing netdev has been removed, or a propagated dev_mc_add() error), the unwind frees the published group without removing it from the tree. A later lookup of the same MGID dereferences the freed struct rxe_mcg from __rxe_lookup_mcg(). Fix this by keeping the new mcg private until rxe_mcast_add() succeeds. Split the tree publication into __rxe_publish_mcg(), call rxe_mcast_add() before taking the tree reference, and free the still-private mcg on failure. Because the group is never visible in mcg_tree until the multicast address is programmed, no concurrent caller can look it up or attach a QP to a group that is about to be torn down, so the error path needs no conditional unwind. If another caller publishes the same MGID while the address is being programmed, the post-add re-check under mcg_lock finds the winner; this caller then drops its private object and balances its own rxe_mcast_add() with rxe_mcast_del() before returning the winner. Reproduced by forcing the rxe_mcast_add() error return under KASAN: without the change the next attach to the same MGID reports a slab-use-after-free in __rxe_lookup_mcg(); with it the forced failure returns cleanly. A no-injection attach/detach regression, including a two-QP shared join/leave and re-attach, stays KASAN- and leak-clean.

Affected packages

Ecosystem Package Introduced Fixed