GPU VulnDB

Database/Kernel, userspace & hypervisor

Linux kernel EFI/CPER: an oversized ARM processor error record is trusted and read past the firmware buffer

CVSS 5.5CVE-2026-43266Kernel, userspace & hypervisorcurated

Impact

The CPER code checks that an ARM processor error section is not too small but never that it is too big. A record claiming a section length of hundreds of megabytes with a large ERR_INFO_NUM is trusted as-is, so the kernel reads and prints far past the end of the firmware memory-mapped area - the example in the fix is a 67-byte record claiming 854918320 bytes. That means kernel log disclosure of whatever lies beyond the buffer and a likely oops when the read leaves mapped memory. This matters on Arm-based accelerator and head nodes, where hardware error records arrive routinely; a crash here takes the node out without a clean drain. Distinct from the firmware-error-record underflow fixed in the same series (CVE-2026-43171): different record type, different check, separate commits.

Who can reach it

Local only, and the malformed input originates from platform firmware rather than a tenant. The resulting memory dump is visible to any local reader of the kernel log. Only applies to Arm hosts processing ARM processor CPER sections.

What to do

Apply the stable kernel update that bounds section_length and ERR_INFO_NUM, then reboot each affected Arm node. No runtime workaround exists; restricting dmesg access limits the disclosure half of the problem but not the oops.

References

Related entries

All Kernel, userspace & hypervisor entries

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.