CVE-2026-43266

What it actually does

CVE-2026-43266 is a Linux kernel bounds-checking flaw in the EFI/APEI GHES CPER parser for ARM processor error records. The kernel trusts a firmware-supplied CPER section_length and ERR_INFO_NUM value without ensuring that parsing stays within the actual CPER record buffer. A malformed or malicious ARM processor CPER record can cause the kernel to read and print data beyond the firmware-provided record, producing excessive kernel log output and potentially destabilizing the system. The primary impact is local denial of service through resource exhaustion, kernel log flooding, or crash conditions; confidentiality and integrity impact are not indicated by the published scoring.

Why it matters to the business

Affected Linux systems, particularly ARM platforms using EFI/APEI GHES hardware error reporting, may become unstable or unavailable if malformed firmware error records are processed. Operationally, this can result in host outages, noisy hardware-error logging, degraded monitoring signal quality, disk pressure from oversized logs, and interruption of workloads running on affected systems. The issue is not listed in CISA KEV, has very low EPSS, and has no reported exploit maturity, so urgency is lower than actively exploited internet-facing vulnerabilities, but kernel remediation should still be included in routine patch cycles for exposed ARM Linux fleets.

How an attack unfolds

An attacker needs local access and a way to trigger or influence processing of a malformed ARM processor CPER record through the platform firmware error-reporting path. The malicious record advertises an unrealistically large section_length and/or ERR_INFO_NUM while the actual CPER buffer is much smaller. When Linux GHES/CPER handling processes the record, vulnerable kernels trust those length fields and continue parsing or dumping beyond the end of the valid record buffer. This can generate a very large kernel hardware-error dump and may exhaust logging, CPU, memory, or storage resources, resulting in service degradation or system unavailability. There is no public indication that this vulnerability is being used by named threat actors or ransomware campaigns.

How to fix it

Upgrade the Linux kernel to a vendor release that includes the EFI/CPER fix preventing ARM processor CPER parsing from going past the record buffer. No exact fixed package versions were provided in the input, so use the relevant distribution, appliance, cloud image, or kernel vendor advisory to identify the corrected kernel build. Where immediate patching is not possible, prioritize compensating controls: restrict local shell and code-execution access, disable or tightly control hardware error-injection interfaces, limit access to debugfs/tracefs and platform firmware test mechanisms, enforce log rotation and rate limiting for kernel logs, and monitor for abnormal GHES/APEI hardware-error storms. Avoid untrusted kernel modules and firmware tooling on affected systems.

How to confirm the fix worked

Confirm remediation by verifying that the running kernel version matches a vendor build containing the EFI/CPER ARM processor bounds-check fix, not merely that a patched package is installed pending reboot. Review distribution changelogs or kernel source for logic that rejects ARM processor CPER records when section_length exceeds the available CPER buffer. After rebooting into the fixed kernel, check kernel logs for the corrected behavior, such as reporting that the section length is too big rather than producing an extremely long dump. Do not attempt destructive proof-of-concept testing on production systems; if validation is required, perform controlled CPER/error-injection testing only in an isolated lab on representative ARM hardware or virtual platforms.

Typical attack path

1. Gain local access to an affected Linux system, or obtain another local execution path capable of interacting with platform error-reporting behavior.
2. Cause the system firmware or error-injection mechanism to present a malformed ARM processor CPER record to the kernel.
3. Set CPER fields such as section_length or ERR_INFO_NUM to values much larger than the actual record size.
4. Trigger GHES/CPER processing of the malformed hardware error record.
5. Cause the vulnerable kernel to read and dump data beyond the CPER record buffer, generating excessive hardware-error output.
6. Leverage the resulting log flood, resource exhaustion, or crash behavior to deny service on the host.

How to detect it

To assess prior exploitation or triggering, review kernel logs, system journal, console logs, crash dumps, and centralized SIEM data for GHES/APEI/CPER hardware-error events involving ARM processor error sections with unusually large section lengths, very high ERR_INFO_NUM values, repeated recoverable hardware error messages, or excessive kernel log growth. Useful sources include journalctl -k output, /var/log/kern.log, /var/log/messages, /var/log/syslog, dmesg archives, pstore/ramoops records, kdump/vmcore artifacts, and log-management indexes that ingest kernel facility messages. Look for log sequences where a small CPER size is paired with an extremely large section length, followed by long dumps, kernel soft lockups, OOM events, filesystem-full alerts, service restarts, or host crashes. There are no known named threat actors or ransomware campaigns associated with this issue, so detection should focus on behavioral evidence of malformed CPER records and denial-of-service effects rather than actor-specific infrastructure.

• Hardware error from APEI Generic Hardware Error Source
• section_type: ARM processor error
• section length is too big
• firmware-generated error record is incorrect
• ERR_INFO_NUM is
• section length: 854918320, CPER size: 67
• ERR_INFO_NUM is 46198
• APEI Generic Hardware Error Source
• GHES
• CPER
• Hardware Error]: event severity: recoverable
• Hardware Error]: Error 0, type: recoverable

What your security team should do

• Inventory ARM Linux systems and appliances that use EFI/APEI GHES hardware error reporting, then map them to vendor kernel advisory status.
• Patch affected Linux kernels during the next standard maintenance window, or sooner for systems where untrusted users can obtain local access.
• Ensure systems are rebooted into the fixed kernel after package installation; stale vulnerable kernels remain exploitable until reboot.
• Restrict local access, debug interfaces, hardware error-injection tooling, and kernel module loading on systems that cannot be patched immediately.
• Add monitoring for abnormal kernel hardware-error log volume, GHES/APEI CPER parsing messages, and disk pressure caused by kernel log growth.
• Tune log rotation and kernel log rate-limiting so a CPER dump storm cannot consume critical storage.
• Because EPSS is very low, the vulnerability is not in KEV, and exploit maturity is listed as none, prioritize after actively exploited remote vulnerabilities but do not defer indefinitely on multi-user or high-availability systems.