CVE-2026-74584 in Linux
Summary
by MITRE • 08/22/2026
In the Linux kernel, the following vulnerability has been resolved:
RDMA/bnxt_re: zero shared page before exposing to userspace
bnxt_re_alloc_ucontext() allocates uctx->shpg via __get_free_page(GFP_KERNEL). The buddy allocator does not zero pages without __GFP_ZERO, so the page contains stale kernel data from whatever object most recently freed it.
The page is then mapped into userspace via vm_insert_page() under BNXT_RE_MMAP_SH_PAGE in bnxt_re_mmap(). The driver only ever writes 4 bytes (a u32 AVID) at offset BNXT_RE_AVID_OFFT (0x10) inside bnxt_re_create_ah(); 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 bnxt_re device (typically rdma group membership) can read this data via a single mmap() at pgoff 0 after IB_USER_VERBS_CMD_GET_CONTEXT.
Other shared pages in the same file already use get_zeroed_page() correctly:
drivers/infiniband/hw/bnxt_re/ib_verbs.c srq->uctx_srq_page = (void *)get_zeroed_page(GFP_KERNEL); cq->uctx_cq_page = (void *)get_zeroed_page(GFP_KERNEL);
uctx->shpg is the only outlier. Bring it in line with the existing convention by switching to get_zeroed_page().
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 08/24/2026
The Linux kernel driver for Broadcom NetXtreme-C/E RDMA devices, specifically bnxt_re, contained a critical information disclosure vulnerability stemming from improper memory initialization before exposure to user space. The function bnxt_re_alloc_ucontext allocates a shared page using __get_free_page with the GFP_KERNEL flag but omits the __GFP_ZERO flag. Consequently, the buddy allocator returns a physical page that may contain stale kernel data from previously freed objects rather than zeroed memory. This uninitialized or partially initialized memory is then mapped into userspace via vm_insert_page within the bnxt_re_mmap function under the BNXT_RE_MMAP_SH_PAGE mapping region. While the driver does write four bytes representing a u32 AVID at offset 0x10 during address handle creation, it fails to sanitize the remaining 4092 bytes of the page. This oversight results in the direct exposure of sensitive kernel memory contents to any process that can access the device file descriptor for an RDMA user verbs interface.
The operational impact of this vulnerability allows local users with appropriate group membership, typically rdma group privileges, to read arbitrary kernel memory through a single mmap operation at page offset zero after issuing an IB_USER_VERBS_CMD_GET_CONTEXT command. This constitutes a significant security risk as it enables the leakage of sensitive data such as stack canaries, cryptographic keys, process credentials, or pointers that could facilitate further exploitation attempts like return-oriented programming attacks. The vulnerability aligns with CWE-200: Information Exposure and is categorized under ATT&CK technique T1083: File and Directory Discovery when considering the broader context of reconnaissance, though more accurately it represents an improper restriction of information flow to unauthorized actors as described in CWE-209 or CWE-537 if viewed through the lens of internal state exposure. The flaw highlights a common class of errors where developers assume memory allocation functions provide sanitized buffers without explicitly requesting zeroing behavior.
Mitigation for this issue involves ensuring that all shared pages exposed to userspace are properly initialized before mapping. In this specific case, the fix replaces __get_free_page(GFP_KERNEL) with get_zeroed_page(), which internally ensures the returned page is cleared of any previous contents. This change brings bnxt_re in line with existing conventions used elsewhere in the same driver for shared receive queue and completion queue pages, where get_zeroed_page() was already correctly implemented. System administrators should apply kernel updates that include this patch to prevent potential information leakage through RDMA interfaces on affected systems. Additionally, defense-in-depth strategies such as restricting access to /dev/infiniband/uverbsX devices to only necessary users and groups can reduce the attack surface for exploitation of similar vulnerabilities in other drivers or future regressions.