CVE-2026-64512

What it actually does

This flaw is an improper input validation issue in the Linux kernel ACPI CPPC code path. The kernel misinterprets the ACPI Generic Address Structure access_width field for Platform Communications Channel regions, allowing values larger than expected to be used in a bit-shift calculation. On affected systems, crafted or malformed ACPI CPPC data can trigger an Undefined Behavior Sanitizer warning such as a shift-out-of-bounds condition in drivers/acpi/cppc_acpi.c during CPU performance initialization or CPPC frequency control operations. The most realistic technical impact is a kernel warning, crash, or denial of service on systems configured to panic on warnings or sanitizer findings; direct remote code execution is not indicated by the available information.

Why it matters to the business

Operational risk is generally low because exploitation requires control over low-level platform firmware, ACPI tables, a malicious virtual machine platform, or equivalent privileged hardware/firmware influence. Systems using ACPI CPPC for CPU performance management, especially ARM64 servers, virtualized platforms, or newer kernel deployments, may experience boot-time instability, kernel warnings, or service disruption if exposed to malformed firmware data. The vulnerability is not listed in CISA KEV, is not known to be used in ransomware campaigns, has no known public exploit maturity, and has a low EPSS score, so remediation should be handled through normal kernel maintenance unless the affected systems are safety-critical, highly available, or run untrusted firmware/virtualization stacks.

How an attack unfolds

An attacker would need a position that lets them influence the ACPI data consumed by the Linux kernel, such as compromised system firmware, malicious hardware, a hostile hypervisor presenting ACPI tables to a guest, or another privileged mechanism capable of modifying platform description tables. The attacker supplies ACPI CPPC register information where the address space is Platform Communications Channel but the access_width value is outside the range expected by the normal system-memory or system-I/O access paths. When the kernel initializes CPPC-based CPU frequency control or writes performance settings, the vulnerable code uses the malformed value in a shift calculation, triggering undefined behavior and a UBSAN shift-out-of-bounds report. Depending on kernel configuration and runtime policy, this may only be logged, or it may escalate into a kernel oops, panic, failed boot, or loss of service availability. There is no current evidence of broad in-the-wild exploitation or ransomware use.

How to fix it

Apply a Linux kernel update that includes the ACPI CPPC fix validating the region type and access_width handling for Platform Communications Channel regions. Because no product-specific fixed versions were provided, use the fixed kernel packages from the relevant Linux distribution, hardware vendor, cloud image provider, or upstream stable kernel branch once available. As compensating controls, restrict use of untrusted hypervisors and firmware, keep BIOS/UEFI and platform firmware updated, avoid booting production systems on unvalidated hardware images, and review whether kernel panic-on-warn or sanitizer panic settings are appropriate for production availability requirements. Where CPPC functionality is not required and vendor guidance supports it, disabling affected CPU frequency/CPPC functionality may reduce exposure, but kernel patching is the preferred remediation.

How to confirm the fix worked

Confirm remediation by verifying the running kernel version or vendor package changelog includes the ACPI CPPC access_width validation fix for this issue. Reboot into the patched kernel and confirm the system no longer logs UBSAN shift-out-of-bounds messages from drivers/acpi/cppc_acpi.c during boot, CPU frequency driver initialization, or CPU performance state changes. On Linux systems, inspect kernel logs with journalctl -k, dmesg, or centralized log collection for the relevant call trace strings. For exposure assessment, identify systems using ACPI CPPC/cppc_cpufreq and prioritize those running affected pre-fix kernels, ARM64 platforms, virtual machines on less-trusted hypervisors, and systems configured to panic on warnings or UBSAN events.

Typical attack path

1. Gain the ability to control or influence firmware-provided ACPI tables, virtual platform ACPI presentation, or equivalent privileged platform metadata.
2. Craft ACPI CPPC register descriptors using a Platform Communications Channel address space with an unexpected access_width value.
3. Cause the Linux kernel to initialize or interact with CPPC CPU performance controls, commonly during boot, udev-triggered device initialization, CPU frequency driver loading, or performance state changes.
4. Trigger the vulnerable cpc_write/cppc_set_perf code path in the ACPI CPPC subsystem.
5. Induce a UBSAN shift-out-of-bounds condition that may produce kernel warnings, an oops, a panic, boot instability, or denial of service depending on system configuration.

How to detect it

Look for evidence of prior triggering in kernel logs rather than network telemetry, because this issue is exercised through local platform ACPI/firmware data and not through a typical remote service request. Relevant sources include dmesg output, journalctl -k, /var/log/kern.log, /var/log/messages, crash dump records, kdump/vmcore metadata, hypervisor console logs for guests, and centralized Linux kernel log pipelines. Search for UBSAN shift-out-of-bounds messages referencing drivers/acpi/cppc_acpi.c, cpc_write, cppc_set_perf, cppc_cpufreq, or ACPI CPPC initialization. Correlate findings with boot times, kernel upgrades, firmware updates, VM migration, hypervisor changes, CPU frequency driver loading, and unexpected reboots. If such artifacts appear without an approved firmware, kernel, or hypervisor change, investigate platform integrity, ACPI table provenance, and whether a malicious or misconfigured hypervisor/firmware image could have supplied malformed ACPI data.

• UBSAN: shift-out-of-bounds in drivers/acpi/cppc_acpi.c
• shift exponent 32 is too large for 32-bit type 'int'
• __ubsan_handle_shift_out_of_bounds
• cpc_write
• cppc_set_perf
• cppc_cpufreq_cpu_init
• [cppc_cpufreq]
• ACPI: CPPC
• ACPI_ADR_SPACE_PLATFORM_COMM
• Comm: (udev-worker)
• panic_on_warn
• /var/log/kern.log
• /var/log/messages

What your security team should do

• Prioritize kernel updates through the normal OS patch cycle; accelerate for systems where kernel warnings cause panic/reboot, where uptime is critical, or where firmware/hypervisor trust is limited.
• Inventory Linux systems using ACPI CPPC or cppc_cpufreq and correlate them with kernel versions that do not yet include the fix.
• Review dmesg, journalctl -k, and centralized kernel logs for UBSAN shift-out-of-bounds reports involving drivers/acpi/cppc_acpi.c, cpc_write, cppc_set_perf, or cppc_cpufreq_cpu_init.
• Ensure BIOS/UEFI, server platform firmware, and hypervisor platforms are updated and sourced from trusted vendors.
• Assess production kernel settings such as panic_on_warn and sanitizer panic behavior to balance security diagnostics with service availability.
• Treat confirmed occurrences as potential platform integrity events if they appear on systems with untrusted firmware, unexpected hypervisor changes, or unexplained ACPI table modifications.