CVE-2026-43277
Awaiting Analysis Awaiting Analysis - Queue
Buffer Overflow in Linux Kernel APEI/GHES

Publication date: 2026-05-06

Last updated on: 2026-05-06

Assigner: kernel.org

Description
In the Linux kernel, the following vulnerability has been resolved: APEI/GHES: ensure that won't go past CPER allocated record The logic at ghes_new() prevents allocating too large records, by checking if they're bigger than GHES_ESTATUS_MAX_SIZE (currently, 64KB). Yet, the allocation is done with the actual number of pages from the CPER bios table location, which can be smaller. Yet, a bad firmware could send data with a different size, which might be bigger than the allocated memory, causing an OOPS: Unable to handle kernel paging request at virtual address fff00000f9b40000 Mem abort info: ESR = 0x0000000096000007 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x07: level 3 translation fault Data abort info: ISV = 0, ISS = 0x00000007, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 swapper pgtable: 4k pages, 52-bit VAs, pgdp=000000008ba16000 [fff00000f9b40000] pgd=180000013ffff403, p4d=180000013fffe403, pud=180000013f85b403, pmd=180000013f68d403, pte=0000000000000000 Internal error: Oops: 0000000096000007 [#1] SMP Modules linked in: CPU: 0 UID: 0 PID: 303 Comm: kworker/0:1 Not tainted 6.19.0-rc1-00002-gda407d200220 #34 PREEMPT Hardware name: QEMU QEMU Virtual Machine, BIOS unknown 02/02/2022 Workqueue: kacpi_notify acpi_os_execute_deferred pstate: 214020c5 (nzCv daIF +PAN -UAO -TCO +DIT -SSBS BTYPE=--) pc : hex_dump_to_buffer+0x30c/0x4a0 lr : hex_dump_to_buffer+0x328/0x4a0 sp : ffff800080e13880 x29: ffff800080e13880 x28: ffffac9aba86f6a8 x27: 0000000000000083 x26: fff00000f9b3fffc x25: 0000000000000004 x24: 0000000000000004 x23: ffff800080e13905 x22: 0000000000000010 x21: 0000000000000083 x20: 0000000000000001 x19: 0000000000000008 x18: 0000000000000010 x17: 0000000000000001 x16: 00000007c7f20fec x15: 0000000000000020 x14: 0000000000000008 x13: 0000000000081020 x12: 0000000000000008 x11: ffff800080e13905 x10: ffff800080e13988 x9 : 0000000000000000 x8 : 0000000000000000 x7 : 0000000000000001 x6 : 0000000000000020 x5 : 0000000000000030 x4 : 00000000fffffffe x3 : 0000000000000000 x2 : ffffac9aba78c1c8 x1 : ffffac9aba76d0a8 x0 : 0000000000000008 Call trace: hex_dump_to_buffer+0x30c/0x4a0 (P) print_hex_dump+0xac/0x170 cper_estatus_print_section+0x90c/0x968 cper_estatus_print+0xf0/0x158 __ghes_print_estatus+0xa0/0x148 ghes_proc+0x1bc/0x220 ghes_notify_hed+0x5c/0xb8 notifier_call_chain+0x78/0x148 blocking_notifier_call_chain+0x4c/0x80 acpi_hed_notify+0x28/0x40 acpi_ev_notify_dispatch+0x50/0x80 acpi_os_execute_deferred+0x24/0x48 process_one_work+0x15c/0x3b0 worker_thread+0x2d0/0x400 kthread+0x148/0x228 ret_from_fork+0x10/0x20 Code: 6b14033f 540001ad a94707e2 f100029f (b8747b44) ---[ end trace 0000000000000000 ]--- Prevent that by taking the actual allocated are into account when checking for CPER length. [ rjw: Subject tweaks ]
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2026-05-06
Last Modified
2026-05-06
Generated
2026-05-07
AI Q&A
2026-05-06
EPSS Evaluated
N/A
NVD
CVE-2026-43277
EUVD
EUVD-2026-27675
Affected Vendors & Products
Showing 1 associated CPE
Vendor Product Version / Range
linux linux_kernel 6.19.0-rc1-00002-gda407d200220
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-UNKNOWN
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

This vulnerability exists in the Linux kernel's APEI/GHES subsystem, where the function ghes_new() attempts to prevent allocating records larger than a defined maximum size (64KB). However, the actual memory allocation is based on the number of pages from the CPER BIOS table, which can be smaller than the size checked. A malicious or faulty firmware could send data larger than the allocated memory, causing the kernel to access invalid memory and resulting in a kernel OOPS (crash).


How can this vulnerability impact me? :

The impact of this vulnerability is that a system running the affected Linux kernel could experience a kernel crash (OOPS) due to improper handling of CPER record sizes. This could lead to system instability, denial of service, or unexpected reboots if exploited by malicious firmware or corrupted data.


How can this vulnerability be detected on my network or system? Can you suggest some commands?

This vulnerability manifests as a kernel OOPS related to memory allocation issues in the APEI/GHES subsystem when handling CPER bios table records. Detection involves monitoring kernel logs for specific error messages indicating a kernel paging request failure or OOPS related to ghes_new() or CPER record handling.

You can check your system logs (e.g., using dmesg or journalctl) for error messages similar to the following:

  • dmesg | grep -i 'Unable to handle kernel paging request'
  • journalctl -k | grep -i 'Internal error: Oops'
  • journalctl -k | grep -i 'ghes_new'

These commands help identify if the kernel has encountered the specific memory allocation fault caused by malformed CPER records from firmware.


What immediate steps should I take to mitigate this vulnerability?

The primary mitigation is to update the Linux kernel to a version that includes the fix for this vulnerability, which ensures proper allocation size checks for CPER bios table records in the APEI/GHES subsystem.

Until the kernel is updated, consider the following steps:

  • Monitor and restrict firmware updates or configurations that might send malformed CPER data.
  • Limit or disable ACPI error reporting features if feasible, to reduce exposure to the vulnerable code path.
  • Ensure system backups and recovery plans are in place in case of kernel crashes.

However, the definitive solution is to apply the kernel patch that correctly handles CPER record allocation sizes.


Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart