CVE-2026-64227

What it actually does

This is a Linux kernel input-validation flaw in ACPI-related platform drivers. A platform device can be forced to bind to a driver through the platform bus driver_override mechanism even when that device does not actually have the ACPI companion object the driver expects. Affected drivers dereference ACPI_COMPANION() or ACPI_HANDLE() without first checking for NULL, which can cause a kernel NULL pointer dereference during probe. The most likely technical outcome is a local kernel crash or service disruption; arbitrary code execution is not indicated by the available details.

Why it matters to the business

Systems running vulnerable Linux kernels may be susceptible to local denial-of-service if an attacker or misconfigured privileged process can manipulate platform device driver binding. Impact is most relevant for servers, appliances, embedded systems, and endpoint fleets where kernel crashes cause downtime, failover, workload interruption, or loss of availability. Current public exploitation likelihood appears low: EPSS is low, the issue is not in CISA KEV, and no known exploit maturity is reported.

How an attack unfolds

An attacker first needs local access with sufficient privileges to interact with sysfs platform-bus driver binding controls, or they must compromise a privileged component that can write to those controls. The attacker identifies a platform device that lacks the ACPI companion object expected by one of the affected ACPI platform drivers. They then use the driver_override mechanism to force that device to match a driver it would not normally match and trigger probe by binding the device to that driver. During probe, the vulnerable driver assumes ACPI_COMPANION() or ACPI_HANDLE() is valid and dereferences a NULL pointer. This causes a kernel oops or panic depending on kernel configuration, resulting in local denial-of-service and possible reboot.

How to fix it

Update the Linux kernel to a version that includes the upstream fix adding NULL checks for ACPI_COMPANION() or ACPI_HANDLE() in the affected ACPI platform drivers. If vendor package versions are not yet identified, use the latest kernel security update from the applicable Linux distribution or device vendor and verify that the fix for this issue is included in the changelog or advisory. As interim mitigation, restrict privileged shell access, restrict write access to sysfs, monitor and control use of /sys/bus/platform/*/driver_override and driver bind/unbind interfaces, and prevent untrusted workloads from obtaining host-level privileges or broad device-management capabilities.

How to confirm the fix worked

Confirm the running kernel has been updated to a vendor build containing the fix, not merely that a package was installed. Check the active kernel with uname -a and compare it with the vendor advisory or fixed package metadata. Review kernel changelogs for the ACPI driver change that validates ACPI_COMPANION() or ACPI_HANDLE() before use during probe. Where safe and appropriate in a non-production test system, validate that forced platform-driver binding to a device without an ACPI companion no longer causes a kernel oops and instead fails cleanly, typically with -ENODEV or another controlled error.

Typical attack path

1. Gain local access to the Linux system or compromise a process with permission to write to platform-bus sysfs controls.
2. Enumerate platform devices and drivers under /sys/bus/platform/.
3. Select a platform device that does not have the ACPI companion object expected by a target ACPI platform driver.
4. Write a chosen driver name to the device's driver_override attribute.
5. Bind or rebind the platform device to the forced driver.
6. Trigger the driver's probe routine and cause a NULL pointer dereference in kernel space.
7. Cause a kernel oops, panic, reboot, or availability disruption.

How to detect it

Look for evidence of abnormal platform driver binding followed by kernel faults. Relevant log sources include auditd, Linux kernel logs, journald, dmesg history, endpoint telemetry, sysfs file-write monitoring, and crash dump systems such as kdump or systemd-coredump where configured. Search for writes to platform-bus driver_override attributes and bind or unbind files shortly before kernel oops, panic, reboot, watchdog reset, or service outage events. In audit logs, focus on open/write activity against /sys/bus/platform/devices/ and /sys/bus/platform/drivers/. In kernel logs, look for NULL pointer dereference, Oops, panic, or stack traces involving platform driver probing, ACPI companion or handle lookup, or device_match_driver_override. Absence of logs does not prove absence of exploitation because a kernel panic can interrupt logging before records are flushed.

• /sys/bus/platform/devices/*/driver_override
• /sys/bus/platform/drivers/*/bind
• /sys/bus/platform/drivers/*/unbind
• driver_override
• device_match_driver_override
• ACPI_COMPANION
• ACPI_HANDLE
• BUG: kernel NULL pointer dereference
• Oops:
• Kernel panic
• RIP:
• platform_probe

What your security team should do

• Prioritize patching Linux systems where untrusted users, containers, automation, or appliance-management services may obtain elevated local privileges.
• Track distribution advisories for the exact fixed kernel package and ensure systems reboot into the updated kernel after installation.
• Harden access to sysfs and platform-bus driver binding interfaces; only trusted administrative processes should be able to write driver_override, bind, or unbind controls.
• Add monitoring for writes to /sys/bus/platform/devices/*/driver_override and /sys/bus/platform/drivers/*/bind or unbind, especially on production systems where such activity is rare.
• Review recent kernel crash, oops, panic, and reboot events for signs of forced driver binding preceding the failure.
• Because this is not currently KEV-listed and has low EPSS, treat it as a normal kernel availability-risk patch unless exposure conditions make local privileged misuse likely.