GPU VulnDB

Database/Firmware, BMC & network fabric

Linux kernel bnxt_re: doorbell page allocation reports success when ioremap fails, leaving unwound driver state

CVSS 9.2CVE-2026-72496Firmware, BMC & network fabriccurated

Impact

bnxt_qplib_alloc_dpi() returned success even when the ioremap of the doorbell page failed, so the RDMA stack continued with a doorbell mapping that does not exist and with the allocation only partly unwound. On a GPU node this driver is the RoCE path used by Broadcom NICs for NCCL/RDMA traffic, so the affected code runs on every QP/doorbell-page allocation by any process holding an RDMA device. The practical exposure is a kernel fault or corrupted driver state on the ioremap failure path rather than a directly steerable primitive; ioremap failure normally requires memory or vmalloc-address-space pressure. The kernel maintainers' CVSS places it at 9.2 with changed scope, but the record gives no exploitation detail beyond the missing rollback, so treat the severity as the error path's worst case rather than a demonstrated attack.

Who can reach it

Local. A process that can open an RDMA device (verbs character device) and allocate doorbell pages, under conditions where ioremap fails. No remote or unauthenticated path is described in the record. Not reachable on nodes with no bnxt_re device.

What to do

Pick up the fixed stable kernel for your series (five stable commits are linked from the record; the record names no single fixed version). Applying it means rebooting each node with a Broadcom RoCE NIC, which on a GPU fleet is a drain-and-reboot per node. Nodes that use Mellanox/ConnectX RDMA instead of bnxt_re are unaffected and need no window.

References

Related entries

All Firmware, BMC & network fabric entries

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.