CVE-2026-43201

What it actually does

This flaw is an out-of-bounds access / invalid dereference in the Linux kernel APEI/GHES ARM processor error handling path. When the kernel parses a malformed, truncated, or unexpectedly small ACPI GHESv2 ARM Processor Error record, it may read fields such as section_length or ctx_info->size before confirming that the record is large enough. On affected ARM systems, this can trigger a kernel Oops and potentially panic or reboot the system, causing a local denial of service. The issue is availability-focused; there is no indication from the provided data that it enables data theft, privilege escalation, or remote code execution.

Why it matters to the business

An affected Linux ARM system can crash when it processes a malformed hardware error record, which can interrupt workloads, cause node reboots, reduce service availability, and create operational instability that may be difficult to distinguish from hardware or firmware faults. The risk is highest for systems that expose hardware error injection or low-level ACPI/GHES interfaces to local users or privileged containers. EPSS is very low, the issue is not listed in CISA KEV, and no public exploit maturity is reported, so broad internet-scale exploitation is unlikely; however, organizations running critical ARM Linux infrastructure should still prioritize vendor kernel updates because the consequence is a full system outage.

How an attack unfolds

An attacker needs local access and a way to cause the kernel to process a malformed ARM GHES/CPER hardware error record. In a plausible scenario, the attacker first obtains a local account or execution context on an affected ARM Linux host. They then abuse exposed hardware error injection functionality, misconfigured debugfs interfaces, or another local mechanism capable of submitting or triggering malformed GHES records. When the kernel’s APEI/GHES path receives a very small or incomplete ARM Processor Error section, the vulnerable parsing logic advances through the record and dereferences fields without adequate length checks. The invalid access occurs in the ARM hardware error logging path, such as log_arm_hw_error or ghes_handle_arm_hw_error, resulting in a kernel Oops. Depending on kernel panic settings and service supervision, the system may crash, reboot, or leave affected workloads unavailable until recovery.

How to fix it

Upgrade to a Linux kernel build that includes the upstream fix adding length validation for small or incomplete ARM Processor Error GHESv2 records in the APEI/GHES handling path. Because no exact fixed versions were provided, use the fixed kernel packages from the relevant Linux distribution or hardware vendor advisory for CVE-2026-43201. If immediate patching is not possible, reduce exposure by disabling or tightly restricting hardware error injection interfaces, avoiding unnecessary debugfs exposure, limiting CAP_SYS_ADMIN and other high-privilege local access, and ensuring untrusted workloads cannot access host-level ACPI/GHES or error-injection facilities. Treat mitigations as temporary; the durable fix is a patched kernel.

How to confirm the fix worked

Confirm that deployed kernels include the vendor patch for the APEI/GHES ARM processor error bounds checks. Validate package status with the distribution’s security tracker and compare the running kernel version using uname -r against the vendor-fixed release. After patching, reboot into the fixed kernel and confirm the old vulnerable kernel is not still active. Review boot logs with journalctl -k or dmesg for APEI/GHES initialization and for absence of recurring Oops messages in log_arm_hw_error or ghes_handle_arm_hw_error. Where safe and authorized in a test environment only, use controlled hardware error injection or vendor-provided validation tooling to confirm malformed or truncated records are rejected without causing an Oops.

Typical attack path

1. Gain local execution on an affected Linux ARM system.
2. Determine whether ACPI APEI/GHES and ARM processor error reporting are enabled.
3. Identify a way to trigger or inject malformed hardware error records, such as exposed error-injection/debug interfaces or a privileged local path.
4. Submit or cause a truncated GHESv2 ARM Processor Error / CPER record to be processed by the kernel.
5. The kernel parses the incomplete record and dereferences fields beyond the allocated record length.
6. The host experiences a kernel Oops, panic, reboot, or service disruption.

How to detect it

Look for evidence of kernel crashes or near-crashes in kernel logs, crash dumps, and RAS telemetry rather than network indicators. Relevant sources include journalctl -k, dmesg, /var/log/kern.log, /var/log/messages, systemd-journald, pstore/ramoops, kdump vmcores, rasdaemon logs, ACPI/GHES/APEI logs, and hypervisor console logs for virtual ARM systems. Search for kernel Oops or panic events involving log_arm_hw_error, ghes_handle_arm_hw_error, APEI, GHES, CPER, or ARM Processor Error records. Correlate crash timing with local user activity, sudo usage, CAP_SYS_ADMIN workloads, container escapes/misconfigurations, debugfs access, loading of error-injection modules, or writes to APEI/EINJ interfaces. Repeated crashes with similar stack traces may indicate either exploitation or faulty firmware/hardware generating malformed records; preserve vmcores and pstore data before reboot cycles overwrite them. There are no reliable remote network IOCs for this vulnerability based on the provided information.

• log_arm_hw_error
• ghes_handle_arm_hw_error
• Internal error: Oops
• ARM Processor Error
• APEI
• GHES
• CPER
• kacpi_notify
• acpi_os_execute_deferred
• ctx_info->size
• section_length
• /sys/kernel/debug/apei/einj
• /sys/kernel/debug/apei
• einj
• rasdaemon
• kernel panic
• Oops: 0000000096000005

What your security team should do

• Inventory Linux ARM systems and prioritize those running kernels with ACPI APEI/GHES enabled.
• Apply vendor kernel updates that include the fix; reboot systems to ensure the patched kernel is active.
• Restrict local access to hosts where hardware error injection, debugfs, or low-level ACPI/GHES interfaces are available.
• Audit use of /sys/kernel/debug, APEI EINJ, and similar error-injection features; disable them where not operationally required.
• Monitor kernel logs for Oops or panic events referencing GHES, APEI, ARM Processor Error handling, log_arm_hw_error, or ghes_handle_arm_hw_error.
• Ensure kdump, pstore, ramoops, or equivalent crash capture is enabled on critical systems so suspected exploitation or firmware-triggered crashes can be investigated.
• Because KEV is false, ransomware use is not reported, and EPSS is low, handle as a stability and availability patch rather than an emergency internet-facing remote compromise issue unless local untrusted access exists.