CVE-2026-89588

What it actually does

A length-accounting bug in the Linux kernel ACPI APEI GHES path (ghes_handle_arm_hw_error) subtracts the pointer size instead of the cper_sec_proc_arm structure size after advancing past the ARM processor-error header. Remaining-length is therefore overstated, so the parser of cper_arm_err_info records can read past the CPER section when err_info_num is large relative to error_data_length. The result is a kernel out-of-bounds read of adjacent memory that can crash the host and, depending on how subsequent typed error-info fields are consumed, may escalate into kernel memory disclosure or memory corruption. Impact is limited to ARM Linux builds that process ACPI GHES/CPER ARM processor-error sections. Local attack vector, no user interaction, and CVSS rates confidentiality, integrity, and availability all high.

Why it matters to the business

ARM Linux systems that use ACPI hardware-error reporting (typical of many ARM servers and ACPI-based ARM platforms) can panic, leak kernel memory, or in a worst case lose kernel integrity, causing outage, data exposure, or full host compromise. The issue is not listed in CISA KEV, is not associated with ransomware, has no public exploit maturity, and EPSS remains very low and flat (~0.00185 over 30 days), so mass opportunistic exploitation is unlikely today; residual risk is still material for multi-tenant or high-assurance ARM fleets because a successful local trigger yields kernel-level impact. Published about five weeks ago with no vendor product/version matrix in this record, so exposure depends on whether production kernels already include the GHES length-accounting fix.

How an attack unfolds

An attacker with local presence on an affected ARM Linux host needs the kernel to parse a GHES-delivered ARM processor CPER section whose err_info_num is large compared with error_data_length. That record can originate from firmware, a virtual firmware/error-injection interface, or any path that feeds APEI GHES. After skipping the cper_sec_proc_arm header, the buggy remaining-length math treats leftover bytes as more cper_arm_err_info records than actually exist, so the parser walks off the end of the section and interprets neighboring kernel memory as error-info structures. Those out-of-bounds fields can cause an oops/panic (denial of service), disclose adjacent kernel data, or drive further GHES handling on attacker-influenced type/length values. No named threat actors, KEV campaigns, or public exploits are associated with this CVE.

How to fix it

Apply a Linux kernel update that includes the ACPI APEI GHES fix for ARM section length accounting in ghes_handle_arm_hw_error() (use sizeof(*err) after skipping the cper_sec_proc_arm header so remaining length matches the pointer advance). No specific distro or upstream version numbers were provided in this record—obtain the patched kernel from your distribution or stable tree, confirm the change is present, and reboot onto the new kernel. Prioritize ARM64 hosts that enable ACPI and GHES/APEI. There is no complete userspace workaround; until patched, restrict local untrusted code and disable nonessential firmware/error-injection interfaces that can feed GHES.

How to confirm the fix worked

Inventory ARM Linux systems with ACPI and APEI/GHES enabled (for example via kernel config, dmesg APEI/GHES messages, or /sys firmware ACPI presence). Confirm the running kernel includes the GHES ARM length-accounting fix by checking that ghes_handle_arm_hw_error() reduces remaining length with sizeof(*err) (structure size), not sizeof(err) (pointer size), or by matching the installed kernel to your vendor advisory. After upgrade, reboot and verify uname and package changelog show the patched build. Re-scan images and golden AMIs so unrepaired kernels are not redeployed.

Typical attack path

1. Obtain local execution or another path that causes the ARM Linux kernel to process ACPI APEI GHES records
2. Cause handling of an ARM processor CPER section with a large err_info_num relative to error_data_length
3. Kernel advances past the cper_sec_proc_arm header but under-subtracts remaining length (pointer size vs structure size)
4. GHES parser continues reading cper_arm_err_info records past the CPER section into adjacent kernel memory
5. Out-of-bounds data is treated as hardware-error records, producing a kernel oops, information leak, or further memory-safety failure
6. Attacker converts the condition into denial of service or, if corruption is achievable, kernel-level compromise

How to detect it

There is no public exploit, named actor, or KEV/ransomware association, so hunting is for crash and GHES-processing artifacts rather than a known campaign. Review kernel logs (journald/dmesg/serial console, vmcore/kdump, pstore) around ACPI APEI/GHES handling for oops, BUG, or paging faults whose backtrace includes ghes_handle_arm_hw_error, ghes_proc, or related APEI CPER ARM processor-error parsing. Correlate with unexpected ARM processor-error notifications, firmware-first error storms, or use of error-injection interfaces shortly before a panic. Persistent crash dumps showing an out-of-bounds read while walking cper_arm_err_info after the ARM section header are the strongest sign the bug was hit; benign GHES informational messages alone are not evidence of exploitation.

• ghes_handle_arm_hw_error
• cper_sec_proc_arm
• cper_arm_err_info
• APEI: Hardware error from APEI Generic Hardware Error Source
• Kernel oops/BUG/paging-request call traces containing ghes_proc or apei_ghes
• err_info_num

What your security team should do

• Immediately identify ARM Linux hosts that use ACPI APEI/GHES and schedule kernel updates that contain the GHES ARM section-length fix, then reboot
• Until patched, limit local untrusted workloads and disable unused hardware-error injection or firmware-emulation interfaces that can deliver CPER records to GHES
• Track vendor/stable kernel advisories for exact package versions; this record does not list fixed versions, so do not assume a given N-1 kernel is safe
• Add kernel-oops monitoring for GHES/APEI ARM processor-error paths; EPSS is low and the CVE is not in KEV, but kernel memory-safety bugs remain high impact if triggered
• Rebuild and recertify ARM golden images, containers-with-custom-kernels, and long-lived appliances so the unfixed GHES code does not persist