CVE-2026-89587

What it actually does

The Linux kernel ACPI Platform Firmware Runtime Update (PFRU) driver copies four firmware-supplied ACPI _DSM buffers (code_type, drv_type, platform_id, oem_id) into fixed 16-byte fields of a stack-allocated pfru_update_cap_info structure in query_capability(), invoked from pfru_ioctl(). memcpy uses the firmware-provided length with no check against the destination size, so a buffer longer than 16 bytes overwrites adjacent kernel stack (observed under KASAN as writes tens of bytes past the frame). The result is kernel stack memory corruption with high impact on confidentiality, integrity, and availability: privilege escalation to kernel/root, arbitrary kernel memory corruption, or an oops/panic.

Why it matters to the business

Linux systems that load the ACPI PFRU driver can be crashed or fully taken over by a local low-privileged actor working with malicious, compromised, or attacker-controlled firmware/ACPI, causing host outage, data theft, and persistent kernel-level compromise. This is especially material on multi-tenant, developer, virtualization, and firmware-update hosts. Exploitation likelihood is currently low (EPSS about 0.14% and flat over 30 days), the issue is not in CISA KEV, and no public exploit or ransomware use is reported 37 days after publication—but kernel memory-corruption bugs still warrant prompt patching wherever the driver is present.

How an attack unfolds

A local attacker who can invoke the PFRU capability-query ioctl, together with ACPI firmware (or emulated/virtual firmware or tampered ACPI tables) that returns _DSM buffers longer than 16 bytes, causes the kernel to memcpy those buffers into 16-byte stack slots. The overflow corrupts the pfru_ioctl() stack frame and neighboring kernel stack. From there the attacker can disrupt kernel control flow or memory, escalate to full OS control, or panic the host. No extra user interaction is required, privileges needed are low if the PFRU device is reachable, and impact stays on the same machine. There is no known in-the-wild exploitation, named threat actor, or public exploit as of this writing.

How to fix it

Apply Linux kernel updates from your distribution or upstream that include the ACPI pfr_update query_capability() fix: validate each _DSM buffer length against the 16-byte destination before copying and return -EINVAL on oversized buffers. No package-specific fixed versions were supplied with this record, so track distro security advisories for kernels that ship that bounds check. If a patched kernel is not yet available, unload or disable the pfr_update driver on hosts that do not need Platform Firmware Runtime Update, and restrict open/ioctl on the PFRU device node to trusted administrators only. Keep firmware and ACPI tables from trusted sources.

How to confirm the fix worked

Confirm the running kernel (uname -r and distro CVE/advisory mapping) includes the pfr_update query_capability() length checks, or that the pfr_update module/driver is not loaded (lsmod, /proc/modules, and kernel config such as ACPI PFRUT). Review device node presence and permissions (typically /dev/pfr_update). In source or debug builds, verify each of the four capability buffer copies is gated by a length check against 16 bytes. Do not validate by feeding oversized _DSM buffers or crash/KASAN reproducers on production systems.

Typical attack path

1. Obtain local access on a Linux host that has the ACPI PFRU driver loaded and a reachable PFRU device/ioctl.
2. Arrange oversized ACPI _DSM capability buffers (malicious, compromised, or virtualized/emulated firmware, or attacker-influenced ACPI tables).
3. Open the PFRU device and issue the capability-query ioctl so query_capability() runs.
4. Kernel memcpy uses firmware lengths into 16-byte stack fields and overflows the pfru_ioctl() stack frame.
5. Use the resulting kernel stack corruption to escalate to kernel/root privileges or to crash the host.

How to detect it

This is a local kernel stack overflow with no network payload, so look for host artifacts after the fact: kernel ring buffer and journal (dmesg, journalctl -k) for oops/panic or KASAN stack-out-of-bounds with pfr_update, pfru_ioctl, or query_capability on the call trace; crash dumps/vmcore from unexpected reboots around firmware-update or ACPI _DSM activity; audit or LSM logs for open/ioctl on /dev/pfr_update by unprivileged users; and module load of pfr_update on hosts that should not perform Platform Firmware Runtime Update. There are no public exploit families, ransomware notes, or named APTs to key on. Absence of these logs does not prove the bug was unused if the host panicked without persistent logging.

• /dev/pfr_update
• pfru_ioctl
• query_capability
• pfr_update
• PFRU_IOC_QUERY_CAP
• stack-out-of-bounds
• KASAN

What your security team should do

• Inventory Linux hosts for the pfr_update/ACPI PFRUT driver and PFRU device nodes and prioritize those images for kernel updates.
• Deploy vendor/distro kernels that reject oversized _DSM buffers in query_capability(); do not wait for KEV or EPSS movement.
• Until patched, restrict PFRU device access and disable the driver where Platform Firmware Runtime Update is unused.
• Treat unexpected kernel oops/panic with pfr_update, pfru_ioctl, or query_capability in the trace as a security event and capture vmcore.
• Hunt retrospectively for non-admin open/ioctl of the PFRU device and for KASAN/stack-out-of-bounds reports involving this path.
• Ensure firmware and ACPI tables are signed/trusted and limit who can load custom ACPI in labs and hypervisors.