Cloudanix VulnDB

CVE-2026-93114

None

CVSS

—

EPSS

0.2%

Published

Sep 17, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A bug in Linux kernel driver code could let a local user crash the whole system by tricking the driver into using a missing hardware reference.

Exploitation
Local Privilege
Attacker needs
High Privilege
Complexity
Moderate
Impact
Denial Of Service
Component
OS kernel
Class
Memory Corruption
Remediation
Patch
Effort
Medium
Patch risk
Low

What it actually does

NULL pointer dereference in san_probe() when ACPI_COMPANION() returns NULL after device_match_driver_override() forces a mismatched driver binding, causing a crash during GSBUS address space handler installation.

Why it matters to the business

Local denial of service via kernel panic on systems where an attacker can trigger driver overrides, with low exploitability but potential for disruption in multi-tenant or shared hardware environments; no ransomware or KEV usage observed 37 days after publication with stable low EPSS.

How an attack unfolds

An attacker with local access uses device_match_driver_override to bind the surface acpi-notify driver to a platform device lacking an ACPI companion object; during probe the code dereferences the NULL result of ACPI_COMPANION leading to an immediate kernel oops.

How to fix it

Apply the upstream fix that adds an explicit ACPI_COMPANION NULL check returning -ENODEV in san_probe before any dereference; rebuild and deploy the patched kernel across all affected distributions.

How to confirm the fix worked

Confirm the presence of the NULL check on ACPI_COMPANION in san_probe source, or verify that force-binding the driver to a non-ACPI device now cleanly returns -ENODEV without oops.

Typical attack path

  1. Obtain local code execution on the target system
  2. Identify or create a platform device without an ACPI companion
  3. Force the acpi-notify driver to match that device via sysfs override
  4. Trigger driver probe which dereferences NULL ACPI companion
  5. Kernel crashes with NULL pointer dereference in san_probe

How to detect it

Search kernel logs and dmesg for oops traces containing san_probe, ACPI_COMPANION, or GSBUS handler installation failures; correlate with recent sysfs writes to driver_override on platform devices.

  • san_probe
  • ACPI_COMPANION
  • NULL pointer dereference
  • GSBUS address space handler

What your security team should do

  • Prioritize kernel updates containing the referenced ACPI companion check patch
  • Monitor kernel logs for NULL dereference oops mentioning san_probe or acpi-notify
  • Restrict unprivileged access to driver_override sysfs interfaces where possible

The record

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.

Affected packages

Ecosystem Package Introduced Fixed