CVE-2026-68425
High · 7.1CVSS
7.1
EPSS
0.3%
Published
Aug 10, 2026
CISA due date
—
Cloudanix analysis
A problem in the Linux kernel's handling of certain high-speed network responses could let nearby attackers waste system resources and interfere with those connections.
- Exploitation
- Adjacent Network
- Attacker needs
- None
- Complexity
- Low
- Impact
- Denial Of Service
- Component
- OS kernel
- Class
- Improper Input Validation
- Remediation
- Patch
- Effort
- Medium
- Patch risk
- Low
What it actually does
Unsolicited or reordered RMPP DATA responses can allocate or extend kernel RMPP receive state before full TID, management class, and source address validation occurs against outstanding sends.
Why it matters to the business
Systems using InfiniBand fabrics may experience resource exhaustion or denial-of-service conditions in kernel MAD handling, disrupting high-performance interconnects used in storage, HPC, and networking clusters.
How an attack unfolds
An attacker on the same InfiniBand subnet sends bursts of unmatched RMPP responses that pass initial high-TID filtering; these responses trigger reassembly state creation before ib_find_send_mad() can reject them, allowing the attacker to consume kernel resources without a corresponding request.
How to fix it
Update to a Linux kernel containing the fix that requires ib_find_send_mad() to succeed before any RMPP reassembly state is created. Apply the patch referenced in the commit that enforces the match for kernel-handled RMPP DATA responses.
How to confirm the fix worked
Confirm the kernel version contains the change that drops unmatched RMPP responses prior to reassembly; review MAD agent code for the early ib_find_send_mad() guard and test with synthetic unmatched RMPP traffic to verify drops occur without state allocation.
Typical attack path
- Attacker gains adjacency on the InfiniBand fabric
- Sends crafted or replayed RMPP DATA segments with matching high TID bits but invalid full TID/source
- Kernel MAD agent allocates RMPP receive state before matching check
- Repeated segments exhaust receive resources or trigger further processing
- Legitimate traffic is impacted by resource contention or state table growth
How to detect it
Inspect kernel logs for MAD/RMPP receive state allocation patterns without corresponding send matches; look for unusual growth in RMPP reassembly buffers or repeated unmatched response handling in ib_mad or rdma subsystems.
What your security team should do
- Prioritize kernel upgrades on all systems exposing InfiniBand/RDMA interfaces
- Monitor for upstream stable kernel releases containing the IB/mad RMPP fix
- Restrict InfiniBand subnet access to trusted peers where feasible
- Review MAD agent logging for unexpected RMPP state growth after patching
The record
In the Linux kernel, the following vulnerability has been resolved: IB/mad: Drop unmatched RMPP responses before reassembly Kernel-handled RMPP receive processing starts reassembly for active DATA responses before the response is matched to an outstanding send. The normal match happens later, after ib_process_rmpp_recv_wc() has either assembled a complete message or consumed the segment. That ordering lets an unsolicited response that routes to a kernel RMPP agent by the high TID bits allocate or extend RMPP receive state before the full TID and source address are checked against a real request. A reordered burst can therefore reach the receive-side insertion path even though the response would not match any send. For kernel-handled RMPP DATA responses, require the existing ib_find_send_mad() match before entering RMPP reassembly. The matcher already checks the full TID, management class and source address/GID against the agent wait, backlog and in-flight send lists. If there is no match, drop the response without creating RMPP state. This leaves the RMPP window behavior unchanged and only rejects responses that have no corresponding request.
Affected packages
| Ecosystem | Package | Introduced | Fixed |
|---|