CVE-2026-93153: RDMA/bng_re: return a timeout when firmware responses stall
In the Linux kernel, the following vulnerability has been resolved:
RDMA/bngre: return a timeout when firmware responses stall
waitforresp() documents that it returns a non-zero error when a firmware command does not complete, and bngrercfwsendmessage() already marks the firmware as stalled when the helper returns -ENODEV.
However, the helper ignores waiteventtimeout() 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 FIRMWARESTALLDETECTED and returns -ETIMEDOUT to the command issuer.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Compensating control
For RDMA/bng_re firmware responses, treat a timed-out wait as firmware stalled when the helper returns -ENODEV, so the firmware command is not treated as successfully completed.
Event History
Frequently Asked Questions
What conditions trigger the affected behavior?
A firmware command response must stall: the response slot remains in use after the command wait times out and after a polled CREQ service attempt fails to produce a response.
What is the operational impact of a stalled firmware response on an unpatched system?
The command path can begin another full timeout period repeatedly, potentially waiting forever instead of reporting completion failure to the command issuer.
How does the fix change failure handling?
It returns -ENODEV when a timed-out wait still has no response. The existing caller marks FIRMWARE_STALL_DETECTED and returns -ETIMEDOUT to the command issuer.