CVE-2026-93277: RDMA/bnxt_re: Validate udata before executing commands
In the Linux kernel, the following vulnerability has been resolved:
RDMA/bnxtre: Validate udata before executing commands
The destroy callbacks currently zero the udata output after tearing down driver resources. If the userspace access fails, uverbs preserves the uobject and allows the destroy callback to run again, even though the driver resource has already been freed.
Call ibnoudataio() before teardown so udata failures are detected while the resource is still intact, then return success after teardown completes.
As part of this change, move ibrespondemptyudata() to the start of the create and modify flows. While this is not strictly required for general create flows, as the core layer unwinds uobjects on failure, it is necessary for create AH. In rdmacreateah(), the HW object is otherwise leaked.
Affected Software
Event History
Frequently Asked Questions
What conditions are required to trigger this issue?
The issue involves RDMA bnxt_re uverbs operations where userspace udata access fails during destroy processing. The affected paths include destroy callbacks, and the fix also adjusts create and modify flows, including create AH handling.
What can happen if userspace access fails during a destroy operation?
The uverbs layer can preserve the uobject and invoke the destroy callback again after the driver resource was already freed. This can cause the callback to operate after teardown; create AH failures can also leak the hardware object.
How does the fix prevent repeated teardown and resource leaks?
The fix checks for udata I/O before tearing down driver resources, so failures are detected while the resource remains intact. It also sends empty udata responses at the start of create and modify flows, which is required to avoid a hardware-object leak in the create AH path.