Cloudanix VulnDB

CVE-2026-93153

None

CVSS

—

EPSS

0.2%

Published

Sep 17, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A timing bug in hardware communication handling can make certain network features stop responding forever instead of recovering after a delay.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
Moderate
Impact
Denial Of Service
Component
OS kernel
Class
Denial of service
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

The __wait_for_resp helper ignores wait_event_timeout expiry, allowing an infinite retry loop when a firmware response slot remains occupied after a polled CREQ attempt, instead of returning -ENODEV and marking firmware stalled.

Why it matters to the business

RDMA operations on affected Linux systems can hang indefinitely under firmware stall conditions, disrupting high-performance networking and storage workloads with potential service degradation.

How an attack unfolds

An adversary or environmental condition induces a firmware command stall; the flawed wait loop never terminates, blocking the command issuer and potentially exhausting resources or causing denial of service.

How to fix it

Apply the upstream kernel commit that returns -ENODEV after a timed-out wait in __wait_for_resp; rebuild and deploy the patched kernel across all affected hosts.

How to confirm the fix worked

Inspect the RDMA/bng_re source for the corrected __wait_for_resp implementation that checks wait_event_timeout result and returns -ENODEV; confirm via kernel version or source diff.

Typical attack path

  1. Trigger or observe a firmware response stall in RDMA/bng_re
  2. Invoke bng_re_rcfw_send_message which calls the defective wait helper
  3. Wait event times out but loop restarts instead of erroring out
  4. Firmware stall flag never set and command issuer receives no -ETIMEDOUT

How to detect it

Review kernel logs for repeated firmware command timeouts or RDMA stall messages; correlate with process hangs in RDMA user-space libraries.

What your security team should do

  • Prioritize kernel updates for systems using RDMA/bng_re
  • Test RDMA workloads after patching to verify timeout behavior
  • Monitor firmware command latency and stall indicators in production

The record

In the Linux kernel, the following vulnerability has been resolved: RDMA/bng_re: return a timeout when firmware responses stall __wait_for_resp() documents that it returns a non-zero error when a firmware command does not complete, and bng_re_rcfw_send_message() already marks the firmware as stalled when the helper returns -ENODEV. However, the helper ignores wait_event_timeout() expiry. If the response slot remains in use after the timeout and after the polled CREQ service attempt, the loop starts another full timeout period and can repeat forever. Return -ENODEV after a timed out wait that still has no response. The existing caller then marks FIRMWARE_STALL_DETECTED and returns -ETIMEDOUT to the command issuer.

Affected packages

Ecosystem Package Introduced Fixed