CVE-2026-93107: RDMA/rxe: Avoid reprocessing the current packet after the QP enters the error state

Published Sep 17, 2026
·
Updated

In the Linux kernel, the following vulnerability has been resolved:

RDMA/rxe: Avoid reprocessing the current packet after the QP enters the error state

When docomplete() finds the QP in the error state it returns RESPSTCHKRESOURCE. Before commit 49dc9c1f0c7e ("RDMA/rxe: Cleanup reset state handling in rxeresp.c") this was the flush loop: checkresource() had an error-state branch that fetched each remaining recv WQE and completed it with IBWCWRFLUSHERR, without touching the current packet. That commit removed the error-state branch from checkresource() (draining is now done at rxereceiver() entry) but kept the docomplete() error-state return.

As a result, when a QP moves to the error state while a packet is being completed - e.g. an rdmacm disconnect racing with receive processing - the responder state machine loops back into the request processing chain with the already-completed packet still in hand: checkresource() fetches a fresh recv WQE, execute()/senddatain() copies the same packet payload again, docomplete() posts another IBWCSUCCESS CQE (qp->resp.status is still 0), and control returns to the error-state check. The loop re-executes the same packet once per posted recv WQE (observed: ~1000 duplicate IBWCSUCCESS completions of one SEND, one per ~8us, matching the RQ occupancy) until the RQ is exhausted, after which qp->resp.wqe is NULL and senddatain() dereferences it:

BUG: kernel NULL pointer dereference, address: 0000000000000014 Workqueue: rxewq dowork RIP: copydata+0x29/0x1f0 Call Trace: senddatain+0x25/0x50 rxereceiver+0xf36/0x1dd0

The duplicate completions are indistinguishable from real receives to the ULP. During an rds stress test, the message was accepted as new and delivered the same datagram to user space hundreds of times, corrupting the stream; any ULP that relies on RC exactly-once delivery is affected.

A live packet reaching the error-state check in docomplete() has been executed and completed exactly once and must be consumed, not re-processed. Return RESPSTCLEANUP for it (dequeue and free); keep returning RESPSTCHKRESOURCE for the pkt == NULL case.

Affected Software

1 affected component
Linux Kernel

Event History

Sep 17, 2026
CVE Published
via MITRE·04:11 PM
Data Sourced
via MITRE·04:11 PM
Description

Frequently Asked Questions

1

Which systems are exposed to this issue?

Systems using the Linux kernel's RDMA/rxe responder path are exposed when a queue pair can enter the error state during receive processing. The described trigger includes an rdma_cm disconnect racing with packet completion.

2

What must happen for the flaw to be triggered?

A packet must be in the process of being completed when the queue pair transitions to the error state. In that state, do_complete() returns a resource-check status while the already-completed packet remains available for request processing.

3

What behavior could indicate that the issue has occurred?

The same packet payload may be copied repeatedly into newly fetched receive WQEs, and multiple IB_WC_SUCCESS completion queue entries may be posted for that same packet. This happens because the responder state machine re-enters request processing with the current packet still in hand.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203