Cloudanix VulnDB

CVE-2026-98354

None

CVSS

—

EPSS

0.2%

Published

Oct 6, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A bug in how the system handles certain network messages on high-speed connections can slowly use up memory when bad messages arrive, potentially slowing down or crashing the machine.

Exploitation
Remote Unauthenticated
Attacker needs
None
Complexity
Low
Impact
Denial Of Service
Component
OS kernel
Class
Memory Corruption
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

A receive buffer (ib_mad_private) is leaked when ib_mad_enforce_security() fails because the buffer is not yet linked to rmpp_list, so ib_free_recv_mad() finds nothing to free, and the caller assumes ownership was transferred.

Why it matters to the business

Repeated leaks can exhaust memory on systems using RDMA/InfiniBand, leading to degraded performance or crashes over time from remote unprivileged senders.

How an attack unfolds

An attacker sends multiple MAD packets with incorrect PKey values to an RDMA-enabled system, triggering the security enforcement failure path repeatedly without buffer cleanup.

How to fix it

Apply the kernel patch that links recv_buf to rmpp_list immediately after initialization.

How to confirm the fix worked

Verify the fix by inspecting the ib_mad_complete_recv function for the corrected linking order; monitor memory usage under MAD traffic.

Typical attack path

  1. Identify RDMA-enabled target
  2. Craft and send MADs with invalid PKey
  3. Repeat to accumulate leaks
  4. Monitor for memory exhaustion

How to detect it

Monitor kernel memory usage and slab allocations for ib_mad_private; look for increasing counts without corresponding activity.

What your security team should do

  • Update Linux kernel to include the RDMA MAD fix
  • Monitor systems for unusual memory growth in RDMA contexts
  • Restrict PKey access if possible

The record

In the Linux kernel, the following vulnerability has been resolved: RDMA/mad: Fix receive buffer leak when PKey enforcement fails ib_mad_complete_recv() initializes mad_recv_wc->rmpp_list and then runs ib_mad_enforce_security() before linking recv_buf onto that list. On failure it calls ib_free_recv_mad(), which only walks rmpp_list and frees the ib_mad_private of every buffer found there. As the list is still empty at that point, nothing is freed at all. The caller cannot clean up either: ib_mad_recv_done() sets recv to NULL right after ib_mad_complete_recv() returns, assuming the MAD layer took ownership of the buffer. Every MAD that fails the PKey check therefore leaks one ib_mad_private (about 300 bytes per IB port MAD, ~2K for OPA), and a remote node can trigger this repeatedly by sending MADs with a wrong PKey. Link recv_buf onto rmpp_list right after the list is initialized, so the error path has something to free.

Affected packages

Ecosystem Package Introduced Fixed