Skip to main content

Linux Kernel EUVDEUVD-2026-82215

| CVE-2026-93107 HIGH
2026-09-17 Linux GHSA-86fh-qj8h-2fhq
Denial Of Service Linux Suse
8.2
CVSS 3.1 · Vendor: Linux
View

Attack ChainAIDerived

Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain

  1. Access
    Establish RC connection over Soft-RoCE (rxe)
  2. Delivery
    Trigger QP error via rdma_cm disconnect racing receive
  3. Exploit
    Responder re-processes already-completed packet
  4. Execution
    Duplicate IB_WC_SUCCESS completions corrupt ULP stream
  5. Persist
    RQ exhausted, qp->resp.wqe NULL
  6. Impact
    NULL pointer dereference crashes kernel

Vulnerability Assessment

Exploitation Conditions

Requires the target host to use the Linux Soft-RoCE (rxe) software RDMA transport with at least one active Reliable Connection (RC) queue pair carrying receive WQEs. Exploitation depends on a specific race: the QP transitioning to the error state (e.g. an rdma_cm disconnect) coinciding with in-flight receive/completion processing of a live packet. Limiting factors: the rxe driver is not enabled by default in most deployments; a valid established RC connection is needed; and the outcome hinges on winning a narrow timing window rather than a deterministic single request, so reliable triggering is difficult. Affects kernels from 6.4 onward that include commit 49dc9c1f0c7e until the fix.
Impact

The vendor CVSS of 8.2 (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:H) overstates real-world risk. The root cause is a race - an rdma_cm disconnect (QP moving to error state) racing with in-flight receive processing in the Soft-RoCE (rxe) responder state machine - which is not reliably attacker-driven, so AC:L and PR:N are optimistic; a narrow timing window and an established RC connection are actually required, arguing for AC:H and PR:L. The A:H (crash via NULL pointer dereference in copy_data/send_data_in once the RQ is exhausted) is well supported, and the I:L is genuine and notable: duplicate IB_WC_SUCCESS completions (~1000 observed for one SEND) are indistinguishable from real receives, breaking RC exactly-once semantics and corrupting the ULP data stream (demonstrated delivering the same RDS datagram to userspace hundreds of times). There is NO EPSS score, NO CISA KEV listing, and NO public POC in the provided data, so exploitation is not confirmed as widespread or targeted - this is a code-fix-only kernel disclosure. Net: a real correctness/availability bug but not an urgent internet-facing priority; realistic severity is closer to ~5.0-5.5. The 'Denial Of Service' tag is accurate but incomplete, since the flaw also has a data-integrity dimension.
Exploit ScenarioDerived

On a host using the Linux Soft-RoCE (rxe) software RDMA driver with an active RC queue pair, a peer disconnect (rdma_cm) races with receive processing while a packet is being completed. The responder loops back through the request chain, re-executing the already-completed packet once per posted recv WQE, posting hundreds of duplicate IB_WC_SUCCESS completions that corrupt the ULP stream, then dereferences a NULL qp->resp.wqe once the receive queue is drained, crashing the kernel. No public exploit is identified at time of analysis; reproduction was observed under an RDS stress test.
This Week Schedule remediation this week. Why: HIGH severity (CVSS 7.0-8.9).
Patch available 0.2% exploitation probability (EPSS)

Get an e-mail when this CVE is exploited, patched or re-scored. Free account.

Alert me

AnalysisAIv1 – Sep 18, 2026

A race condition in the Linux kernel's RDMA/rxe (Soft-RoCE) responder state machine lets a single received packet be re-executed and re-completed once per posted receive WQE when a queue pair transitions to the error state mid-completion, producing hundreds of duplicate IB_WC_SUCCESS completions that are indistinguishable from genuine receives, then a kernel NULL pointer dereference in copy_data()/send_data_in() once the receive queue is exhausted. Kernels from 6.4 (starting with commit 49dc9c1f0c7e) up to the fix are affected; Soft-RoCE is not enabled by default in most deployments, and our independent assessment scores this CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:L/A:H, well below the vendor's 8.2 (AV:N/AC:L/PR:N/UI:N), because triggering requires an established Reliable Connection queue pair, an active receive queue, and a narrow disconnect/receive timing window rather than a single request. There is no CISA KEV listing and no public exploit code identified at time of analysis.

RemediationAI

Vendor-released patch: upgrade to Linux 6.6.157, 6.12.110, 6.18.52 or 7.2.6 (mainline 7.3-rc1) as appropriate for your branch, which contain the responder fix that returns RESPST_CLEANUP for a live packet already executed and completed while keeping RESPST_CHK_RESOURCE for the pkt == NULL case; the individual stable commits are listed at https://git.kernel.org/stable/c/c319b986a88cedf600c4497cd7814a891b2f9e7c and the sibling links above. Distributions that backport kernel fixes should track their own advisory for the corresponding CVE update, and the NVD record https://nvd.nist.gov/vuln/detail/CVE-2026-93107 tracks the upstream references. If patching cannot be done immediately, the most effective compensating control is to stop loading the Soft-RoCE module: blacklist or modprobe -r rdma_rxe on hosts that do not need software RDMA over Ethernet - side effect is that software RDMA fabrics (e.g. rxe-only RoCEv2 test setups) stop working entirely, so this is only viable where RDMA-capable hardware or no RDMA is in use. For hosts that genuinely need rxe, reduce the attack surface by refusing untrusted RDMA CM connections (restrict who can establish RC queue pairs to trusted peers/subnets, since our assessed vector requires PR:L rather than PR:N) and by avoiding or hardening ULPs such as RDS - the RDS stress test is what turned silent duplicate completions into user-space stream corruption, so disabling RDS over rxe removes the most damaging consequence while leaving the NULL-dereference DoS risk in place. Note the triggering window is narrow and depends on a QP error transition racing receive processing, but since it can panic the kernel, unpatched internet- or peer-reachable rxe endpoints should be treated as a denial-of-service risk until the kernel is updated.

Affected VersionsENISA

Linux 49dc9c1f0c7e396654a31a480328fffd902fa494 <0d37e2503efd1069a74be740eadf63ea17c96810
Linux patch: 6.12.110
Linux 49dc9c1f0c7e396654a31a480328fffd902fa494 <15ae32c4a3551c4c9da457370bdfdd65d171e512
Linux 6.4
Linux patch: 6.6.157
Linux patch: 7.3-rc1
Linux patch: 0
Linux patch: 6.18.52
Linux patch: 7.2.6
Linux 49dc9c1f0c7e396654a31a480328fffd902fa494 <c319b986a88cedf600c4497cd7814a891b2f9e7c
Linux 49dc9c1f0c7e396654a31a480328fffd902fa494 <62a4b48767e06fdd64548450fae2b1ffc6ff5d69
Linux 49dc9c1f0c7e396654a31a480328fffd902fa494 <399713f1f0eac641351c8ceaec0ab8244ddcf78c

Affected Packages

euvd linux no fix

Source: OSV (Open Source Vulnerabilities)

Affects your stack

Affects 1 package in euvd

Checking this CVE against your own stacks and servers is part of the Basic plan and up.

Sign in to check
Technical ContextAI · show details

The vulnerable component is the rxe driver (rdma_rxe), the software RDMA transport that implements RoCEv2 over standard Ethernet so ULPs can use RDMA verbs without RDMA-capable NICs. The bug lives in the responder-side state machine in rxe_resp.c: do_complete() returns RESPST_CHK_RESOURCE whenever it observes the QP in the error state. Before commit 49dc9c1f0c7e, check_resource() had an error-state branch that drained remaining receive WQEs with IB_WC_WR_FLUSH_ERR without touching the current packet; that commit moved draining to rxe_receiver() entry but left the do_complete() error-state return in place, so a live, already-executed packet can loop back through check_resource() -> execute()/send_data_in() -> do_complete() once per posted recv WQE, posting a duplicate IB_WC_SUCCESS CQE each pass (qp->resp.status is still 0). Once the RQ is exhausted, qp->resp.wqe is NULL and send_data_in() dereferences it at offset 0x14, crashing in copy_data() on the rxe_wq workqueue. The root cause class is a race condition combined with a responder state-machine logic error (no CWE was supplied with this record); the required interleaving is an rdma_cm disconnect or similar QP teardown racing with in-flight receive processing of a packet that is already being completed. Because the duplicate completions look identical to legitimate receives, ULPs expecting Reliable Connection exactly-once semantics can process the same payload repeatedly - an RDS stress test delivered one datagram to user space hundreds of times, corrupting the stream - before the NULL dereference causes a kernel panic/DoS.

Know when the next one hits your stack

  • Watch products and get an email when something new is published
  • Check this CVE against your own stack and servers
  • Exploit and PoC references, threat intelligence from 22 sources
Continue with Google Continue with GitHub

No credit card · 7-day full trial

Severity by source

Vendor (Linux) PRIMARY 8.2 HIGH
AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:H
vuln.today AI 5.9 MEDIUM

Network-reachable rxe packet processing but exploitation hinges on a disconnect/receive race (AC:H) and an established QP (PR:L); crash (A:H) plus stream corruption/duplicate delivery (I:L), no disclosure (C:N).

3.1 AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:L/A:H
4.0 AV:N/AC:H/AT:P/PR:L/UI:N/VC:N/VI:L/VA:H/SC:N/SI:N/SA:N
SUSE 5.5 MEDIUM
AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

Primary rating from Vendor (Linux).

CVSS VectorVendor: Linux

Attack Vector
Network
Attack Complexity
Low
Privileges Required
None
User Interaction
None
Scope
Unchanged
Confidentiality
None
Integrity
Low
Availability
High

Lifecycle Timeline

4
CVSS changed
Sep 18, 2026 - 18:22 NVD
8.2 (HIGH)
Patch available
Sep 17, 2026 - 17:19 EUVD
CVE Published
Sep 17, 2026 - 16:11 cve.org
HIGH 8.2
CVE Published
Sep 17, 2026 - 16:11 cve.org
UNKNOWN (no severity yet)

DescriptionCVE.org

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 do_complete() finds the QP in the error state it returns RESPST_CHK_RESOURCE. Before commit 49dc9c1f0c7e ("RDMA/rxe: Cleanup reset state handling in rxe_resp.c") this was the flush loop: check_resource() had an error-state branch that fetched each remaining recv WQE and completed it with IB_WC_WR_FLUSH_ERR, without touching the current packet. That commit removed the error-state branch from check_resource() (draining is now done at rxe_receiver() entry) but kept the do_complete() error-state return.

As a result, when a QP moves to the error state while a packet is being completed - e.g. an rdma_cm disconnect racing with receive processing - the responder state machine loops back into the request processing chain with the already-completed packet still in hand: check_resource() fetches a fresh recv WQE, execute()/send_data_in() copies the same packet payload again, do_complete() posts another IB_WC_SUCCESS 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 IB_WC_SUCCESS completions of one SEND, one per ~8us, matching the RQ occupancy) until the RQ is exhausted, after which qp->resp.wqe is NULL and send_data_in() dereferences it:

BUG: kernel NULL pointer dereference, address: 0000000000000014 Workqueue: rxe_wq do_work RIP: copy_data+0x29/0x1f0 Call Trace: send_data_in+0x25/0x50 rxe_receiver+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 do_complete() has been executed and completed exactly once and must be consumed, not re-processed. Return RESPST_CLEANUP for it (dequeue and free); keep returning RESPST_CHK_RESOURCE for the pkt == NULL case.

Executive ViewAI

Why It Matters

A race condition in the Linux kernel's RDMA/rxe (Soft-RoCE) software driver allows an authenticated peer holding an established Reliable Connection queue pair to induce duplicate and fabricated receive completions, ultimately causing a kernel NULL pointer dereference on affected hosts running kernels from 6.4 onward. Organizations that enable Soft-RoCE - typically software-only RDMA lab, test, or virtualized environments rather than default production builds - face host-level availability loss, while default deployments without the module remain unexposed. The practical risk is concentrated in a definable subset of systems, but those systems should be identified and remediated before the module is relied upon further.

Business Impact: Medium
Compensating Controls

Apply vendor patch. Where patching cannot be completed immediately, unload or blacklist the rdma_rxe module on hosts that do not require Soft-RoCE, and restrict RDMA network reachability to trusted peers for those that do.

Threat Intelligence Overview

EPSS Score
0.2%
Top 90% exploitable
Prevalence
Low
Soft-RoCE (rxe) software RDMA driver is a niche, rarely-deployed kernel feature
Data Quality
3 sources
Confidence: Low
EUVD NVD CVE.org EPSS Vendor

How this decision was reached

The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.

SignalValue
Severity HIGH
CISA KEV No
Public POC No
EPSS 0.2%
Patch available Yes
Active threat No
Deciding rule
HIGH severity (CVSS 7.0-8.9)
What every action level means
Emergency Immediate action required. Criteria: CRITICAL + in CISA KEV (actively exploited) without patch, OR CRITICAL + EPSS > 30% without patch, OR CRITICAL + active threat signals without patch.
Act Now Prioritize within 24-48h. Criteria: in KEV with patch available, OR CRITICAL + public POC, OR HIGH + EPSS > 10%, OR CRITICAL + active threat, OR any CRITICAL severity.
This Week Schedule remediation this week. Criteria: HIGH severity (CVSS 7.0-8.9). Patch within normal change window.
This Month Plan within 30 days. Criteria: MEDIUM severity (CVSS 4.0-6.9), lower exploitation probability. Include in regular patch cycle.
Monitor Track and reassess. Criteria: LOW severity (CVSS 0.1-3.9), minimal exploitation risk. No immediate action needed.

SSVC AssessmentENISA

SSVC Decision· derived
Scheduled
Exploitation· derived
None
System Exposure· derived
Open
Automatable· derived
Yes
Human Impact
Medium

Priority Score

41
Low Medium High Critical
KEV: 0
EPSS: 0
CVSS: +41
PoC: 0
Weaponized: 0
Threat intel: 0
Gov advisory: 0

Attack Technique

Denial of Service MEDIUM

Denial of Service attacks render applications or systems unavailable by overwhelming resources or triggering failure conditions.

Same technique Denial Of Service

View all
CVE-2015-5119 CRITICAL POC
9.8
CVE-2011-2462 CRITICAL POC
9.8
CVE-2011-0611 HIGH POC
8.8
CVE-2012-1889 HIGH POC
8.8
CVE-2012-0507 CRITICAL POC
9.8
CVE-2014-1761 HIGH POC
7.8
CVE-2015-5122 CRITICAL POC
9.8
CVE-2011-0609 HIGH POC
7.8

Vendor StatusVendor

SUSE

Severity: Moderate
Product Status
SUSE Linux Enterprise Desktop 15 SP7 Affected
SUSE Linux Enterprise Desktop 15 SP7 Affected
SUSE Linux Enterprise High Availability Extension 15 SP7 Affected
SUSE Linux Enterprise High Availability Extension 15 SP7 Affected
SUSE Linux Enterprise High Availability Extension 16.0 Affected

References

Advisories & patches
ADVISORY https://nvd.nist.gov/vuln/detail/CVE-2026-93107 REF https://git.kernel.org/stable/c/0d37e2503efd1069a74be740eadf63ea17c96810 REF https://git.kernel.org/stable/c/15ae32c4a3551c4c9da457370bdfdd65d171e512 REF https://git.kernel.org/stable/c/399713f1f0eac641351c8ceaec0ab8244ddcf78c REF https://git.kernel.org/stable/c/62a4b48767e06fdd64548450fae2b1ffc6ff5d69 REF https://git.kernel.org/stable/c/c319b986a88cedf600c4497cd7814a891b2f9e7c

Search Externally

GitHub PoC Exploit-DB PacketStorm Snyk Rapid7 Nuclei Templates Trickest PoC
Back

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy