CVE-2026-43266 Overview
CVE-2026-43266 is a Linux kernel vulnerability in the EFI Common Platform Error Record (CPER) handling code. The flaw resides in the Generic Hardware Error Source (GHES) subsystem, which processes ARM processor error records reported by firmware via the ACPI Platform Error Interface (APEI). The kernel validates that the section_length field is not too small, but it fails to validate that the value is not too large. A firmware-supplied record containing an inflated ERR_INFO_NUM and an oversized section_length causes the kernel to read past the CPER buffer and dump memory beyond the firmware-mapped region.
Critical Impact
A malformed firmware-generated ARM processor CPER record can cause the Linux kernel to read past the intended buffer boundary, resulting in out-of-bounds memory access during hardware error reporting.
Affected Products
- Linux kernel versions implementing GHES/CPER ARM processor error record parsing
- Systems using EFI/APEI Generic Hardware Error Source reporting on ARM platforms
- Distributions shipping the affected drivers/firmware/efi/cper-arm.c logic
Discovery Timeline
- 2026-05-06 - CVE-2026-43266 published to NVD
- 2026-05-06 - Last updated in NVD database
Technical Details for CVE-2026-43266
Vulnerability Analysis
The vulnerability resides in the Linux kernel's EFI/CPER subsystem responsible for parsing ARM processor error records. When firmware delivers a hardware error event through GHES, the kernel walks the CPER section and iterates over ERR_INFO_NUM substructures based on the declared section_length. The existing logic only rejects records where section_length is too small for the fixed header. It does not bound-check against the actual buffer size delivered by firmware.
An illustrative case from the patch description is a 67-byte CPER record whose header advertises ERR_INFO_NUM of 46198 and section_length of 854918320. The kernel trusts these values and produces an extremely long dump that reads memory well past the firmware memory-mapped area. The fix introduces a sanity check that rejects oversized lengths and reports the record as malformed instead of walking off the buffer.
Root Cause
The root cause is missing upper-bound validation on attacker-influenced or firmware-supplied length fields, classifying this as an out-of-bounds read driven by improper input validation. The parser trusted section_length and ERR_INFO_NUM from the CPER header without cross-checking them against the size of the buffer the kernel actually mapped.
Attack Vector
Exploitation requires a malformed or malicious ARM processor CPER record to be delivered to the kernel through the firmware error reporting path. This is generally a local or firmware-level threat surface rather than a remote network vector. The impact is out-of-bounds memory disclosure in kernel log output and potential denial of service through excessive logging when a firmware-generated error record is incorrect.
No public exploit is available for this issue. See the upstream fixes referenced in the kernel.org commit a68d22902a69 and kernel.org commit 64eb63f573f4 for technical details on the validation logic added to cper-arm.c.
Detection Methods for CVE-2026-43266
Indicators of Compromise
- Kernel log entries containing Hardware Error messages with implausibly large section length values relative to the reported CPER size
- Log lines stating section length is too big or firmware-generated error record is incorrect after applying the patch
- Unusually large ERR_INFO_NUM values reported in APEI Generic Hardware Error Source output
Detection Strategies
- Compare the kernel build version against the upstream stable commits to confirm the GHES/CPER patch is present
- Monitor dmesg and journalctl -k for repeated APEI error events that include suspicious section_type: ARM processor error records
- Audit ARM-based hosts running BMC or firmware that generates synthetic CPER records during testing or fault injection
Monitoring Recommendations
- Forward kernel logs to a centralized logging or SIEM platform and alert on Hardware Error patterns with abnormal length fields
- Track the rate of GHES events per host to identify firmware producing malformed records
- Include kernel package versions in configuration drift baselines for ARM server fleets
How to Mitigate CVE-2026-43266
Immediate Actions Required
- Identify ARM-based Linux systems exposed to APEI/GHES hardware error reporting and prioritize them for patching
- Apply the latest stable kernel update from your Linux distribution that incorporates the upstream CPER bound-check fix
- Validate firmware and BMC versions on affected hardware to ensure they emit well-formed CPER records
Patch Information
The upstream fix adds a check that rejects ARM processor CPER records whose section_length exceeds the actual buffer size and logs the record as incorrect rather than walking past the buffer. The fix has been backported across multiple stable branches. See kernel.org commit 25b290624b0e, kernel.org commit 45766863baf8, kernel.org commit be10c1bdf64a, kernel.org commit c80113dcfc80, kernel.org commit ca2aad8771aa, and kernel.org commit eae21beecb95.
Workarounds
- No supported software workaround exists; the fix must be applied at the kernel source level
- Where patching is delayed, restrict the ability to inject synthetic CPER records via firmware or BMC test interfaces
- Limit physical and management-plane access to ARM systems to reduce exposure to malformed firmware-generated error records
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.
