CVE-2026-74706 in Linux
Summary
by MITRE • 08/22/2026
In the Linux kernel, the following vulnerability has been resolved:
bnge: Fix NULL pointer dereference in aux device release
If allocation of auxr_dev fails during auxiliary device setup, the error path calls auxiliary_device_uninit(), which eventually invokes bnge_aux_dev_release().
The release callback unconditionally dereferences aux_priv->auxr_dev->pdev to retrieve the parent bnge_dev. Since auxr_dev has not yet been allocated on this failure path, the dereference results in a NULL pointer exception
Retrieve the parent bnge_dev from the auxiliary device's parent instead of auxr_dev, and free auxr_dev only when it was successfully allocated. This allows the release callback to correctly clean up partially initialized auxiliary devices.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 08/22/2026
The Linux kernel driver for Broadcom NetEngine (bnge) experienced a critical NULL pointer dereference vulnerability during the initialization phase of its auxiliary device management subsystem. This flaw specifically manifests in the error handling path when the allocation of an internal structure, referred to as auxr_dev, fails. During the setup process for an auxiliary device, if memory allocation returns a failure code, the kernel proceeds to clean up by calling auxiliary_device_uninit(). This function subsequently invokes the release callback bnge_aux_dev_release() to ensure proper resource deallocation and state reset. However, this cleanup routine contains a logic error that assumes certain structures have been successfully allocated even when initialization has not completed.
The technical root cause lies in how the parent device context is retrieved within the release callback. The function attempts to access the parent bnge_dev structure by dereferencing aux_priv->auxr_dev->pdev. In scenarios where the allocation of auxr_dev fails, this pointer remains NULL because the memory was never assigned. Consequently, any attempt to traverse through a null pointer triggers a kernel panic or oops, leading to system instability or a complete denial of service for the affected node. This represents a classic failure in defensive programming practices within device driver code, where error paths do not adequately account for partially initialized states.
From a classification perspective, this vulnerability aligns with CWE-476, which denotes NULL Pointer Dereference. It also relates to CWE-252, Unchecked Return Value, as the code failed to verify the success of memory allocation before proceeding with operations that depend on that allocated resource. In terms of adversary behavior and detection frameworks such as MITRE ATT&CK, this type of vulnerability can be leveraged for Denial of Service (T1499) if triggered remotely or via local privilege escalation vectors. While often considered a stability issue rather than a direct security exploit in many contexts, NULL pointer dereferences in kernel space are particularly severe because they compromise the integrity and availability of the entire operating system environment.
The operational impact of this vulnerability is primarily centered on system reliability. A successful trigger results in an immediate crash or hang of the Linux kernel instance running the affected driver version. For systems relying on Broadcom NetEngine hardware for network processing, such crashes can lead to significant downtime, loss of network connectivity, and potential data corruption if transactions were in progress at the time of the fault. In cloud or virtualized environments where multiple tenants share underlying infrastructure, a single node crash could have cascading effects depending on the deployment architecture.
The resolution implemented by the Linux kernel maintainers addresses this flaw through two key modifications to the release logic. First, the code was updated to retrieve the parent bnge_dev from the auxiliary device's direct parent structure rather than relying on the potentially null auxr_dev pointer. This ensures that even if internal allocation fails, the necessary context for cleanup remains accessible via valid kernel structures. Second, the implementation now checks whether auxr_dev was successfully allocated before attempting to free it. By conditionally freeing only when allocation succeeded, the driver avoids double-free errors and respects the lifecycle of partially initialized objects. These changes ensure that error paths are robust and do not introduce new failure modes during cleanup operations.
To mitigate similar issues in other drivers or systems running affected kernel versions, administrators should apply the latest security patches provided by their distribution vendors. For developers writing Linux kernel modules, it is essential to implement strict checks for allocation failures before dereferencing returned pointers. Additionally, using helper functions that abstract away complex pointer arithmetic and state management can reduce the likelihood of such logical errors. Regular code audits focusing on error handling paths are recommended to identify and rectify similar vulnerabilities in device drivers and subsystems where resource lifecycle management is critical.