CVE-2026-43277

What it actually does

This flaw is a Linux kernel availability vulnerability in the ACPI Platform Error Interface / Generic Hardware Error Source handling path. The kernel limits CPER error records against a maximum size, but it did not also validate the record length against the actual memory allocated for the CPER table location. If firmware, a hypervisor, or another local trigger causes GHES to process an oversized or inconsistent CPER record, the kernel can read past the allocated record buffer while printing or processing the error status, leading to a kernel Oops and potential system crash or service disruption. The practical impact is denial of service rather than data theft or privilege escalation based on the available details.

Why it matters to the business

Affected Linux systems may crash or become unstable when malformed hardware error records are delivered through firmware or virtualization interfaces. This can interrupt workloads, cause node reboots, reduce service availability, and create operational noise in fleets that depend on ACPI/GHES hardware error reporting. The issue is not currently listed in CISA KEV, is not known to be used in ransomware campaigns, has very low EPSS, and has no public exploit maturity reported, so prioritization should focus on exposed high-availability servers, virtualized environments, systems with untrusted local users, and platforms with unreliable or externally controlled firmware/hypervisor layers.

How an attack unfolds

An attacker first needs local access or influence over a component that can cause the kernel to consume a malformed ACPI/GHES CPER hardware error record. In common real-world scenarios, this would require a malicious or compromised hypervisor, malicious firmware, faulty firmware, or access to error-injection mechanisms rather than a purely remote network request. The attacker causes GHES notification handling to run and supplies or triggers a CPER record whose advertised length exceeds the memory actually allocated for the record. When the kernel processes and prints the CPER status, execution reaches the CPER dump path and reads beyond the allocated buffer. This can generate a kernel paging fault, produce an Oops with a stack trace involving GHES and CPER functions, and may crash or destabilize the host or guest, resulting in denial of service.

How to fix it

Apply a vendor-supplied Linux kernel update that includes the fix for the APEI/GHES CPER bounds check. Because no exact fixed package versions were provided, use the fixed kernel versions from the relevant Linux distribution, appliance vendor, cloud image provider, or kernel long-term stable branch. Where immediate patching is not possible, reduce exposure by restricting local shell access, disabling unneeded hardware error injection facilities, keeping system firmware and hypervisors updated, and limiting the ability of untrusted users or guests to influence ACPI/GHES error reporting. As a temporary risk-reduction measure on systems where GHES reporting is not operationally required, evaluate disabling GHES using the kernel boot parameter `ghes.disable=1`; test carefully because this can reduce hardware error visibility and platform diagnostics.

How to confirm the fix worked

Confirm remediation by verifying that the running kernel package or source tree includes the APEI/GHES fix that checks CPER length against the actual allocated record area, not only the maximum GHES status size. Validate the running kernel version with distribution advisories rather than upstream version numbers alone, because vendors backport kernel fixes. Check whether the system uses ACPI APEI/GHES by reviewing kernel configuration and boot logs for GHES registration, such as `CONFIG_ACPI_APEI_GHES` and APEI/GHES messages in `dmesg` or the system journal. After patching, reboot into the fixed kernel and confirm `uname -a` and package inventory report the intended version. For environments that choose mitigation instead of patching, confirm the boot command line contains `ghes.disable=1` and that GHES is not initialized in kernel logs.

Typical attack path

1. Gain local access to the system, control of a guest or host interface, or influence over firmware/hypervisor-delivered ACPI/GHES error records.
2. Trigger a GHES hardware error notification or ACPI HED notification that causes the kernel to process a CPER record.
3. Provide or induce a CPER record with a length larger than the memory region actually allocated for that record.
4. Allow the Linux kernel APEI/GHES path to parse and print the malformed CPER status.
5. Cause an out-of-bounds read during CPER dump/print handling, leading to a kernel Oops and possible crash or reboot.

How to detect it

Look for evidence of kernel Oops, panic, unexpected reboot, or watchdog recovery events that occurred while the kernel was processing ACPI APEI/GHES or CPER records. Useful sources include `dmesg`, `journalctl -k`, `/var/log/kern.log`, `/var/log/messages`, `/var/log/syslog`, persistent journal storage, kdump/vmcore artifacts, crash dump summaries, hypervisor console logs, firmware event logs, and fleet reboot telemetry. Search for stack traces containing CPER and GHES functions such as `hex_dump_to_buffer`, `cper_estatus_print_section`, `__ghes_print_estatus`, `ghes_proc`, `ghes_notify_hed`, and `acpi_hed_notify`. Correlate any such crashes with local user activity, administrative hardware diagnostics, firmware updates, VM migration or host maintenance, machine-check/error-injection activity, and hypervisor events. Because exploitation indicators are mostly crash artifacts rather than durable files or network traffic, absence of these logs does not prove absence of attempted exploitation if logs are not persistent across reboots.

• Unable to handle kernel paging request
• Internal error: Oops
• Workqueue: kacpi_notify acpi_os_execute_deferred
• hex_dump_to_buffer
• print_hex_dump
• cper_estatus_print_section
• cper_estatus_print
• __ghes_print_estatus
• ghes_proc
• ghes_notify_hed
• acpi_hed_notify
• acpi_ev_notify_dispatch
• APEI
• GHES
• CPER
• ghes.disable=1

What your security team should do

• Patch affected Linux kernels through the operating system or appliance vendor, prioritizing production servers, virtualization hosts, critical workloads, and multi-user systems.
• Inventory systems with ACPI APEI/GHES enabled and identify where firmware, hypervisor, or local users could trigger hardware error reporting paths.
• Review kernel crash, reboot, and Oops telemetry for GHES/CPER stack traces to determine whether systems have already experienced this failure mode.
• Update platform firmware, VM firmware, and hypervisors where applicable, because malformed CPER data can originate below the operating system.
• Restrict access to local error-injection, debugging, and hardware-management interfaces to trusted administrators only.
• If patching is delayed and hardware error reporting is not required, test `ghes.disable=1` as a temporary mitigation with operational stakeholders.
• Track vendor advisories for exact fixed kernel builds, especially for long-term support distributions that backport fixes without changing to the latest upstream kernel version.