CVE-2026-93153 in Linux
Summary
by MITRE • 09/18/2026
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.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 09/18/2026
The Linux kernel contains a critical logic flaw within the RDMA/bng_re subsystem, specifically in the firmware communication handling mechanism. This vulnerability arises from an improper implementation of wait conditions when interacting with hardware firmware. The core issue resides in the __wait_for_resp() helper function, which is designed to manage synchronous responses from the device's firmware. According to its documentation and intended behavior, this function should return a non-zero error code if a firmware command fails to complete within the expected timeframe. However, the current implementation neglects to properly handle the expiration of the wait_event_timeout call. This oversight creates a scenario where the system fails to detect when a response has not arrived after the allotted time limit expires.
The operational consequence of this defect is an infinite loop that can cause significant resource exhaustion and potential denial of service conditions for systems relying on RDMA connectivity over Broadcom hardware. When the wait period elapses without receiving a firmware response, the code does not immediately break out or return an error as intended. Instead, it proceeds to attempt a polled CREQ service operation. If this subsequent check also fails to find a valid response slot because the previous timeout was ignored, the control flow loops back and initiates another full timeout period. This cycle repeats indefinitely, consuming CPU cycles and blocking other operations that depend on the RDMA subsystem or the specific device driver involved.
From a technical perspective, this vulnerability represents a failure in proper state management during asynchronous hardware communication protocols. The existing caller of __wait_for_resp() is partially prepared to handle such errors by marking firmware as stalled when it receives an -ENODEV error code. However, because the helper function does not return this specific error upon timeout expiration, the higher-level logic never triggers the stall detection mechanism. Consequently, the system remains in a hung state rather than gracefully degrading or reporting the failure to the command issuer. This lack of robustness can lead to kernel hangs or unresponsive network interfaces depending on how heavily the RDMA stack is utilized by applications such as high-performance computing workloads or storage protocols like NVMe over Fabrics.
To mitigate this risk, it is essential that the __wait_for_resp() function be updated to explicitly check for wait_event_timeout expiry and return -ENODEV when no response is received within the specified duration. This change ensures that the calling routine can correctly identify firmware stalls by setting the FIRMWARE_STALL_DETECTED flag and subsequently returning an appropriate timeout error, such as -ETIMEDOUT, back to the original command issuer. Such a fix restores the expected fault tolerance of the driver, allowing it to recover from unresponsive hardware rather than entering an infinite loop. Administrators should ensure that their kernel versions include patches addressing this specific RDMA/bng_re logic flaw and monitor system logs for signs of firmware communication timeouts which may indicate residual instability if the patch is not applied promptly.
This type of vulnerability aligns with CWE-835, specifically loops with unreachable exit conditions, where a loop lacks a proper termination criterion leading to infinite execution. In terms of attack vectors or impact classification under MITRE ATT&CK, this relates to resource exhaustion techniques that can lead to denial of service against local services or system stability. While typically not exploitable for remote code execution due to the nature of kernel-space blocking loops, it poses a severe availability risk by rendering specific hardware functionalities unusable until a reboot occurs. Proper validation of wait conditions and strict adherence to timeout handling protocols are critical standards in robust driver development to prevent such indefinite hangs.