CVE-2026-93114 in Linux
Summary
by MITRE • 09/18/2026
In the Linux kernel, the following vulnerability has been resolved:
platform/surface: acpi-notify: Check ACPI companion before use
Since 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(), platform drivers that rely on the existence of a device's ACPI companion object should verify its presence.
san_probe() dereferences the result of ACPI_COMPANION() when installing the GSBUS address space handler, so force-binding the driver to a device without an ACPI companion leads to a NULL pointer dereference. The dereference was introduced when the probe function was switched from ACPI_HANDLE() to ACPI_COMPANION().
Check the ACPI companion against NULL and return -ENODEV when it is missing, like commit e4865a56d013 ("ACPI: driver: Check ACPI_COMPANION() against NULL during probe") does for the core ACPI platform drivers.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/18/2026
The Linux kernel vulnerability identified in the surface platform subsystem involves a critical null pointer dereference within the acpi-notify handling logic, specifically affecting the san_probe function. This flaw arises from an assumption that every device bound to this driver possesses a valid Advanced Configuration and Power Interface companion object. In standard operation, drivers rely on ACPI data structures to configure hardware-specific behaviors such as address space handlers for General System Bus operations. However, due to the behavior of device_match_driver_override(), it is possible to force-bind a platform driver to a device that does not match its expected list of supported device identifiers. When this forced binding occurs with a device lacking an ACPI companion object, the kernel attempts to access non-existent data structures, leading directly to a system crash or denial of service through a null pointer dereference.
The technical root cause lies in the transition from using ACPI_HANDLE() to ACPI_COMPANION(). The latter macro returns a pointer to the acpi_device structure associated with a device, which is essential for installing GSBUS address space handlers required by Surface hardware drivers. Previously, the code did not sufficiently validate that this companion object existed before dereferencing it. This oversight was introduced when the probe function logic was refactored. Without an explicit check against NULL, any attempt to register the handler on a device without ACPI support results in immediate memory corruption or kernel panic upon execution of the probe routine.
From a security and stability perspective, this vulnerability represents a significant reliability issue that can be exploited locally by users with sufficient privileges to trigger driver binding operations. The impact is primarily a denial of service against the operating system integrity, as the null pointer dereference will crash the kernel thread responsible for device initialization. This aligns with CWE-476, which describes NULL Pointer Dereferences, and falls under MITRE ATT&CK technique T1595.002, Active Scanning: Vulnerability Scanning, if an attacker uses this to probe system stability, though it is more accurately categorized as a local denial of service vector due to the privilege requirements for driver binding manipulation.
To mitigate this vulnerability, developers must implement explicit validation checks within the device probe functions before accessing ACPI-specific resources. The recommended fix involves verifying that the result of ACPI_COMPANION() is not NULL prior to any subsequent operations that depend on it. If the companion object is absent, the function should return -ENODEV to indicate that no suitable hardware was found for this driver instance. This approach mirrors best practices established in core ACPI platform drivers and ensures graceful failure rather than catastrophic system crashes when dealing with mismatched or unsupported device configurations.