In the Linux kernel, the following vulnerability has been resolved:
RDMA/bnxt_re: Proper rollback if the ioremap fails
bnxt_qplib_alloc_dpi returns success even if ioremap fails.
Add the proper rollback when the ioremap fails and return
-ENOMEM status.
CVSS Vector: CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:C/C:L/I:H/A:H
CVSS Score: 9.2
AV:L - The flaw is reached only through local RDMA uverbs ioctl/write on /dev/infiniband/uverbs* (ibv_alloc_pd and BNXT_RE_ALLOC_WC_PAGE call bnxt_qplib_alloc_dpi); remote RoCE packet handling and in-kernel RDMA target/server paths never invoke this DPI setup routine.
AC:L - An attacker can induce vmalloc/ioremap failure with local memory pressure, then repeatedly invoke alloc_pd or WC-page allocation; each call deterministically leaves a consumed DPI with NULL dbr, and subsequent create_cq/QP/SRQ doorbell rings fault without races or uncontrollable layout.
PR:N - ib_uverbs creates per-device character nodes as mode 0666, so any local process can open uverbs, allocate a context, and call alloc_pd or alloc_page without CAP_SYS_ADMIN, init-namespace root, or other elevated capabilities on typical HPC/cloud RDMA hosts.
UI:N - Exploitation requires only the attacker's own RDMA verbs sequence (alloc_context, alloc_pd or alloc_page, then create_cq/QP/SRQ and I/O); no cooperative action by another user, administrator, or victim mounting devices or opening files is needed.
S:C - On Kubernetes/HPC hosts exposing bnxt_re to tenant containers or unprivileged RDMA workloads, triggering host-kernel NULL doorbell writes or exhausting finite DPI indices from a workload crosses the container/tenant security boundary to the hypervisor/host authority.
C:L - Returning success after failed ioremap leaves DPI metadata and a mmapable BAR doorbell offset active while kernel dpi->dbr stays NULL, disclosing doorbell-index/BAR layout to the caller and enabling follow-on corruption when doorbells are later rung.
I:H - With dpi->dbr left NULL, bnxt_qplib_ring_db and ring_prod_db issue writeq() to NULL during CQ, SQ, RQ, and SRQ doorbell updates on subsequent verbs activity, providing a kernel write primitive and control-flow disruption beyond a benign error return.
A:H - NULL doorbell writeq faults oops or panic the kernel when CQ/QP/SRQ objects are used after the bogus allocation, and each successful-but-broken DPI allocation permanently consumes a finite doorbell index, enabling repeated denial of RDMA service to other tenants.
| Attack Vector |
Local |
Scope |
Changed |
| Attack Complexity |
Low |
Confidentiality Impact |
Low |
| Privileges Required |
None |
Integrity Impact |
High |
| User Interaction |
None |
Availability Impact |
High |
AV:L - The flaw is reached only through local RDMA uverbs ioctl/write on /dev/infiniband/uverbs* (ibv_alloc_pd and BNXT_RE_ALLOC_WC_PAGE call bnxt_qplib_alloc_dpi); remote RoCE packet handling and in-kernel RDMA target/server paths never invoke this DPI setup routine.
AC:L - An attacker can induce vmalloc/ioremap failure with local memory pressure, then repeatedly invoke alloc_pd or WC-page allocation; each call deterministically leaves a consumed DPI with NULL dbr, and subsequent create_cq/QP/SRQ doorbell rings fault without races or uncontrollable layout.
PR:N - ib_uverbs creates per-device character nodes as mode 0666, so any local process can open uverbs, allocate a context, and call alloc_pd or alloc_page without CAP_SYS_ADMIN, init-namespace root, or other elevated capabilities on typical HPC/cloud RDMA hosts.
UI:N - Exploitation requires only the attacker's own RDMA verbs sequence (alloc_context, alloc_pd or alloc_page, then create_cq/QP/SRQ and I/O); no cooperative action by another user, administrator, or victim mounting devices or opening files is needed.
S:C - On Kubernetes/HPC hosts exposing bnxt_re to tenant containers or unprivileged RDMA workloads, triggering host-kernel NULL doorbell writes or exhausting finite DPI indices from a workload crosses the container/tenant security boundary to the hypervisor/host authority.
C:L - Returning success after failed ioremap leaves DPI metadata and a mmapable BAR doorbell offset active while kernel dpi->dbr stays NULL, disclosing doorbell-index/BAR layout to the caller and enabling follow-on corruption when doorbells are later rung.
I:H - With dpi->dbr left NULL, bnxt_qplib_ring_db and ring_prod_db issue writeq() to NULL during CQ, SQ, RQ, and SRQ doorbell updates on subsequent verbs activity, providing a kernel write primitive and control-flow disruption beyond a benign error return.
A:H - NULL doorbell writeq faults oops or panic the kernel when CQ/QP/SRQ objects are used after the bogus allocation, and each successful-but-broken DPI allocation permanently consumes a finite doorbell index, enabling repeated denial of RDMA service to other tenants.
CVSS 3.1