CVE-2026-93115 in Linux
Summary
by MITRE • 09/18/2026
In the Linux kernel, the following vulnerability has been resolved:
platform/mellanox: mlxbf-pmc: Check ACPI_COMPANION() against NULL
Every platform driver can be forced to match a device that doesn't match its list of device IDs because of device_match_driver_override(), so platform drivers that rely on the existence of a device's ACPI companion object need to verify its presence.
mlxbf_pmc_probe() passes the result of ACPI_COMPANION() to acpi_device_hid(), which dereferences it, so force-binding the driver to a device without an ACPI companion leads to a NULL pointer dereference.
Accordingly, add a requisite ACPI_COMPANION() check against NULL to the mlxbf-pmc driver and return -ENODEV when the companion is missing.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 09/18/2026
The vulnerability identified in the Linux kernel's mlxbf-pmc platform driver stems from an insufficient validation of device attributes during the probe phase, specifically regarding the presence of an ACPI companion object. In modern Linux kernel architecture, platform drivers are responsible for initializing hardware devices detected by the system bus enumeration mechanisms. While standard matching relies on a predefined list of compatible device identifiers, the kernel provides a mechanism known as device_match_driver_override that allows external agents or configurations to force-bind a driver to a specific device regardless of its actual compatibility with the driver's ID table. This flexibility is crucial for handling legacy hardware or special configuration scenarios but introduces a significant risk if the driver code assumes certain properties exist without explicit verification. The mlxxbf-pmc driver, which manages performance monitoring counters on Mellanox platforms, relies heavily on ACPI (Advanced Configuration and Power Interface) data to identify and configure the device correctly. Specifically, it utilizes the acpi_device_hid function to retrieve a hardware identifier string from the ACPI namespace associated with the device.
The core technical flaw lies in how the driver handles the result of the ACPI_COMPANION macro within its probe routine. This macro is designed to return a pointer to the struct acpi_device structure if one exists for the given platform device, or NULL otherwise. However, prior to this fix, the code passed the direct output of ACPI_COMPANION() to acpi_device_hid without checking whether that pointer was valid. When an external override forces the mlxxbf-pmc driver onto a device that lacks an associated ACPI companion object—such as devices enumerated via Device Tree or PCI where no corresponding ACPI entry exists—the macro returns NULL. Consequently, when acpi_device_pid attempts to dereference this null pointer to access internal structures for extracting the hardware ID, it triggers a kernel panic due to a NULL pointer dereference. This represents a classic memory safety violation where an invalid memory address is accessed, leading to immediate system instability or crash during the device initialization process.
From a security and operational impact perspective, this vulnerability allows for local denial of service conditions if triggered by a privileged user with the ability to manipulate driver bindings via sysfs interfaces. Although exploiting this typically requires root privileges due to the nature of writing to driver bind/unbind files in /sys/bus/platform/drivers/, it highlights a lack of defensive programming practices within kernel subsystems that could potentially be leveraged in more complex attack chains involving privilege escalation or system instability during hot-plug events. The absence of proper input validation for device attributes violates fundamental principles of robust software design, particularly the expectation that drivers must validate all external inputs before use. This flaw is categorized under CWE-476, which denotes a NULL pointer dereference vulnerability, indicating that the program proceeds with an invalid memory reference after checking for conditions but failing to account for edge cases like missing companion objects.
The remediation implemented involves inserting a explicit check for the ACPI_COMPANION result before any subsequent operations are performed on it. By verifying that the returned pointer is not NULL, the driver ensures safe access patterns and prevents the kernel from attempting to dereference invalid memory addresses. If no ACPI companion is found, the probe function now returns -ENODEV, signaling to the kernel core that this specific device instance cannot be supported by the current driver configuration. This approach aligns with best practices for handling optional hardware features where fallback mechanisms or graceful degradation are preferred over catastrophic failures. Furthermore, this fix reinforces adherence to ATT&CK technique T1059, specifically regarding command and script interpretation within operating system environments, as improper validation of input parameters in kernel space can lead to execution flow disruptions that attackers might exploit for persistence or disruption purposes.
To mitigate similar vulnerabilities across the broader Linux ecosystem, developers must adopt a rigorous approach to validating all pointers derived from device enumeration APIs before dereferencing them. This includes checking not only ACPI companions but also Device Tree nodes and other platform-specific data structures when they are accessed conditionally. Security audits of kernel drivers should prioritize identifying patterns where optional features are treated as mandatory without adequate null checks. Additionally, static analysis tools configured to detect potential NULL pointer dereferences in high-risk paths such as probe functions can help identify these issues early in the development lifecycle. Maintaining strict adherence to defensive coding standards ensures that even when external overrides bypass standard compatibility checks, the driver remains resilient against configuration errors or malicious binding attempts that could otherwise lead to system crashes or instability.