CVE-2026-64372

What it actually does

This is a Linux kernel memory-safety flaw in the PCC CPU frequency driver during ACPI _OSC negotiation. The driver frees an ACPI output buffer after the first acpi_evaluate_object() call but does not reset the pointer and length before the second call, causing ACPICA to write into freed kernel memory and later free the same pointer again. On systems where the vulnerable pcc-cpufreq path is reachable, this can result in kernel memory corruption, including use-after-free and double-free conditions. A local authenticated attacker who can trigger the affected CPU frequency / ACPI negotiation path may be able to crash the kernel or, depending on allocator state and platform behavior, potentially escalate privileges or execute code in kernel context.

Why it matters to the business

Successful exploitation could allow a local user or compromised low-privilege process to disrupt affected Linux systems or potentially gain full control of the host. The most immediate operational risk is system instability, kernel panic, or service outage on platforms using the affected PCC CPU frequency driver. Because the issue requires local privileges and there is currently no public exploit maturity indicated, internet-wide exploitation risk is lower than for remote vulnerabilities, but the impact is high for multi-user Linux servers, shared compute environments, virtualization hosts, build systems, and systems where untrusted workloads can run.

How an attack unfolds

An attacker first obtains local access to a Linux system running a vulnerable kernel and where the PCC CPU frequency driver and relevant ACPI _OSC negotiation path are available. The attacker then triggers behavior that causes pcc_cpufreq_do_osc() to perform its two-phase _OSC evaluation. During the first evaluation, the kernel allocates and then frees an ACPI output buffer. Because the vulnerable code leaves stale buffer metadata in place, the second evaluation can write into memory that has already been freed. The cleanup path then attempts to free the stale pointer again. An attacker may try to shape kernel heap state around this sequence so the stale write or double free corrupts useful kernel objects. At minimum, exploitation may cause a kernel crash; in a successful privilege-escalation scenario, the attacker could gain elevated kernel-level privileges. No CISA KEV listing, ransomware association, named threat actor activity, or mature public exploit is indicated for this vulnerability at this time.

How to fix it

Apply the Linux kernel update from the relevant Linux distribution, appliance vendor, cloud image provider, or kernel maintainer that includes the fix for the pcc-cpufreq _OSC buffer handling issue. The corrected code resets output.pointer to NULL and output.length to ACPI_ALLOCATE_BUFFER after freeing the first ACPI result so each _OSC phase receives a fresh buffer. No exact fixed package versions were provided in the input, so remediation should be based on vendor advisories and distribution-specific kernel package versions. If immediate patching is not possible, reduce exposure by limiting local shell access, restricting untrusted workloads, disabling unnecessary access to CPU frequency management interfaces where operationally safe, and considering whether the affected pcc-cpufreq driver can be disabled on systems that do not require it. Mitigations should be tested carefully because CPU frequency and ACPI behavior can affect performance and power management.

How to confirm the fix worked

Confirm the running kernel version and installed kernel packages match a vendor release that contains the fix. Validate both the installed package and the currently booted kernel, because Linux systems may have patched packages installed but still be running an older kernel until rebooted. Check whether the PCC CPU frequency driver is present or loaded using kernel module listings, boot logs, and CPU frequency sysfs paths. Review vendor advisories for backported fixes, since the fixed version number may not clearly indicate upstream patch status. After patching, reboot into the updated kernel, verify the active kernel with uname or equivalent inventory tooling, and confirm no recurring kernel warnings, oopses, KASAN reports, or ACPI _OSC / pcc-cpufreq errors appear during boot, CPU hotplug, or power-management testing.

Typical attack path

1. Gain local authenticated access to an affected Linux system.
2. Confirm the system is running a vulnerable kernel with the PCC CPU frequency driver or affected ACPI CPU frequency path available.
3. Trigger CPU frequency / ACPI _OSC negotiation through normal system interfaces or events that exercise the pcc-cpufreq code path.
4. Manipulate timing or kernel heap layout to increase the chance that the stale ACPI output buffer is reused in a useful way.
5. Cause the second ACPI evaluation to write into freed kernel memory and then trigger the double-free cleanup path.
6. Achieve a denial of service through kernel crash, or in a more advanced scenario, corrupt kernel memory to escalate privileges.

How to detect it

There are no widely reported exploitation campaigns or public exploit maturity indicated, and this vulnerability is not listed as CISA KEV based on the provided data. Detection should focus on signs of attempted local kernel exploitation and system instability rather than a single definitive network indicator. Review kernel logs, persistent journal entries, crash dumps, kdump/vmcore artifacts, audit logs, EDR telemetry, and authentication history around the time of any kernel oops, panic, reboot, or ACPI/pcc-cpufreq warning. Look for KASAN, slab allocator, double-free, use-after-free, general protection fault, or page fault messages referencing pcc_cpufreq_do_osc, pcc-cpufreq, ACPI _OSC, acpi_evaluate_object, kfree, or ACPICA. Correlate those events with local user sessions, sudo activity, unexpected execution of stress/power-management tools, CPU hotplug activity, sysfs writes under CPU frequency paths, or newly dropped local binaries. Because successful kernel exploitation may leave few application-level traces, preserve crash dumps and volatile forensic evidence where possible before rebooting repeatedly.

• pcc_cpufreq_do_osc
• pcc-cpufreq
• acpi_evaluate_object
• ACPI _OSC
• ACPICA
• BUG: KASAN: use-after-free
• BUG: KASAN: double-free
• double free
• use-after-free
• kernel BUG
• kernel panic
• general protection fault
• slab-use-after-free
• kfree
• /sys/devices/system/cpu/cpufreq
• /sys/devices/system/cpu/cpu*/cpufreq

What your security team should do

• Prioritize patching Linux systems that allow local users, shared workloads, containers with weak isolation, CI/CD jobs, high-performance compute users, or other semi-trusted code execution.
• Coordinate with Linux distribution and appliance vendors to identify the exact fixed kernel builds, because no universal fixed package version is provided.
• Reboot systems after kernel updates and verify the running kernel is the patched kernel, not only that packages are installed.
• Inventory systems where the pcc-cpufreq driver is loaded or where PCC/ACPI CPU frequency management is in use, and treat those as higher priority.
• Harden local access controls: remove unnecessary accounts, restrict SSH access, enforce least privilege, and limit sudo/admin delegation.
• Monitor for kernel crashes, kernel memory corruption warnings, ACPI _OSC errors, and pcc-cpufreq-related anomalies, especially on systems with recent local compromise indicators.
• For shared compute and container platforms, review tenant isolation assumptions because local kernel privilege escalation vulnerabilities can break workload boundaries.
• If patching is delayed, assess whether the pcc-cpufreq module or affected CPU frequency features can be disabled without unacceptable performance or power-management impact.