CVE-2026-74584: RDMA/bnxt_re: zero shared page before exposing to userspace
In the Linux kernel, the following vulnerability has been resolved:
RDMA/bnxtre: zero shared page before exposing to userspace
bnxtreallocucontext() allocates uctx->shpg via getfreepage(GFPKERNEL). The buddy allocator does not zero pages without GFPZERO, so the page contains stale kernel data from whatever object most recently freed it.
The page is then mapped into userspace via vminsertpage() under BNXTREMMAPSHPAGE in bnxtremmap(). The driver only ever writes 4 bytes (a u32 AVID) at offset BNXTREAVIDOFFT (0x10) inside bnxtrecreateah(); the remaining 4092 bytes of the page are exposed to userspace unsanitised, leaking kernel memory contents.
Any user with access to /dev/infiniband/uverbsX on a host with a bnxtre device (typically rdma group membership) can read this data via a single mmap() at pgoff 0 after IBUSERVERBSCMDGETCONTEXT.
Other shared pages in the same file already use getzeroedpage() correctly:
drivers/infiniband/hw/bnxtre/ibverbs.c srq->uctxsrqpage = (void )getzeroedpage(GFPKERNEL); cq->uctxcqpage = (void )getzeroedpage(GFPKERNEL);
uctx->shpg is the only outlier. Bring it in line with the existing convention by switching to getzeroedpage().
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
Linux kernelto a version that resolves this vulnerability.Patch RDMA/bnxt_re: zero shared page before exposing to userspace - Configuration
Change the bnxt_re shared page allocation used for uctx->shpg to use get_zeroed_page(GFP_KERNEL) so the remaining bytes are zeroed before mapping to userspace via vm_insert_page().
drivers/infiniband/hw/bnxt_re/ib_verbs.c bnxt_re_alloc_ucontext() allocation of uctx->shpg = use get_zeroed_page(GFP_KERNEL) instead of __get_free_page(GFP_KERNEL)
Event History
Frequently Asked Questions
Who can access the leaked data?
Any local user with access to /dev/infiniband/uverbsX on a host using a bnxt_re RDMA device can access it. This access is typically granted through membership in the rdma group.
What actions are required to trigger the disclosure?
The user must obtain an RDMA user context with IB_USER_VERBS_CMD_GET_CONTEXT, then perform a single mmap() using page offset 0 for the BNXT_RE_MMAP_SH_PAGE mapping. Reading that mapping exposes the shared page contents.
What data is exposed through the mapping?
Only four bytes, the u32 AVID at offset 0x10, are written by the driver. The remaining 4092 bytes can contain stale kernel memory from a previously freed allocation.
How is the issue resolved in the driver?
The affected shared page allocation is changed from __get_free_page(GFP_KERNEL) to a zeroed-page allocation, matching the driver's existing shared-page allocations. Zeroing the page prevents stale kernel data from being mapped into userspace.