Linux RDMA bnxt_re: destroy callbacks re-run against freed resources after a udata failure

CVSS 7.8CVE-2026-93277Firmware, BMC & network fabriccurated

Impact

bnxt_re zeroed its udata output only after tearing driver resources down. If the userspace copy fails, uverbs keeps the uobject and lets the destroy callback run a second time on an already-freed driver resource - a use-after-free / double-free in the Broadcom RoCE provider. A create-AH failure on the same paths leaks the hardware object instead. Exposure is limited to nodes using Broadcom NetXtreme RoCE HCAs, where any tenant holding a verbs device can drive it; the record scores it high on confidentiality, integrity and availability from a local low-privileged user.

Who can reach it

Local user with an RDMA verbs device backed by a Broadcom bnxt_re adapter; the trigger is a deliberately failing userspace copy on a destroy ioctl. No elevated privilege needed. Nodes on Mellanox/NVIDIA or Intel fabric are not affected.

What to do

Install a kernel with the bnxt_re udata-validation commits and reboot the affected nodes; ib_core and bnxt_re are pinned by running RDMA jobs, so drain first. If you have no Broadcom RoCE adapters in the fleet, no action is needed.

References

https://nvd.nist.gov/vuln/detail/CVE-2026-93277 https://git.kernel.org/stable/c/c5643ea4f040acc2f4d1e88f49bd0be51110ff2f https://git.kernel.org/stable/c/d38c835925d4a3bfdf0a85ff2829ee90c709c561

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.