Look up another CVE · open CVE-2026-89588 in the interactive tracker
CVE-2026-89588
ACPI: APEI: GHES: fix ARM section length accounting after header
Published 2026-09-11 (37 days ago) by the Linux kernel CNA. Subsystem drivers/acpi. Debian urgency: unimportant.
What to do, per Debian release
Debian's own status for CVE-2026-89588 in every release this site tracks, and what each one means in practice. Every status below is the one the Debian Security Team publishes for this CVE. source
| Release | Status | Version | What this means |
|---|---|---|---|
| Debian 12bookworm | not affected | 6.1.190-1 | Nothing to do. bookworm never shipped the vulnerable code. |
| Debian 13trixie | fixedDSA-6528-1 · 2026-09-29 · text | 6.12.111-1 | Update the kernel and reboot. DSA-6528-1 shipped the fix on 2026-09-29, in 6.12.111-1. A running kernel keeps the old code until the machine restarts. |
| Debian 14forky | fixed | 7.2.6-1 | Update the kernel and reboot. Fixed in 7.2.6-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.2.6-1 | Update the kernel and reboot. Fixed in 7.2.6-1. A running kernel keeps the old code until the machine restarts. |
| Debian 12bookworm · linux-6.12 | fixedDLA-4817-1 · 2026-10-04 · text | 6.12.111-1~deb12u1 | Update the kernel and reboot. DLA-4817-1 shipped the fix on 2026-10-04, in 6.12.111-1~deb12u1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
In ghes_handle_arm_hw_error(), after skipping the cper_sec_proc_arm header with (err + 1), the remaining length was reduced by sizeof(err) (pointer size) instead of sizeof(*err) (structure size). That overestimates the bytes left for cper_arm_err_info records and can let the parser read past the CPER section when err_info_num is large enough relative to error_data_length. Use sizeof(*err) so the length accounting matches the pointer advance and the earlier sizeof(*err) size check.
Where it lives
The fix touches these files. If the subsystem is one you do not use, the practical exposure is lower, though the package is still the vulnerable one.
drivers/acpi/apei/ghes.c
- What this is
- ACPI APEIMAINTAINERS section matched on drivers/acpi/apei/ · linux-acpi@vger.kernel.org
Check it on the machine
grep -wE 'CONFIG_ACPI|CONFIG_ACPI_APEI|CONFIG_ACPI_APEI_GHES' /boot/config-$(uname -r)Reads the booted kernel's own configuration, on the machine and nowhere else. =y is built in, =m is a module, and an is not set line means the code is not there.
Show whether Debian builds this, per release
Debian builds this, but not on every flavour. At least one release below builds the code on some of its kernel flavours and not on others, so the answer depends on the architecture and flavour installed.
- bookwormYnot built on armhf/armmp, armhf/armmp-lpae, armhf/rt/armmp, ppc64el/powerpc64le
- trixieYnot built on armel/rpi, armhf/armmp, armhf/armmp-lpae, armhf/rt/armmp, ppc64el/powerpc64le, ppc64el/powerpc64le-64k, riscv64/riscv64, s390x/s390x
- forky, sidYnot built on armhf/armmp, armhf/armmp-lpae, loong64/loong64, ppc64el/powerpc64le, ppc64el/powerpc64le-64k, riscv64/riscv64, s390x/s390x
- bookworm · linux-6.12Ynot built on armhf/armmp, armhf/armmp-lpae, armhf/rt/armmp, ppc64el/powerpc64le, ppc64el/powerpc64le-64k
- Y
- built in where it is built at all; some flavours do not build it
- Build switches
- CONFIG_ACPI, CONFIG_ACPI_APEI, CONFIG_ACPI_APEI_GHES
- Reads as
- all on means the file is compiled; any one off means it is not.
From the configuration Debian publishes for every kernel flavour it builds. It covers only the architectures Debian ships a linux-config package for, and nothing about a kernel you built yourself. Debian's own status above stays authoritative about the source package.MAINTAINERS kbuild Makefiles Debian linux-config packages
Signals
- Published
- 2026-09-11 (37 days ago)source
- CVSS
- 8.4 high
CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:Hsource recompute it - Attack vector
- local (AV:L)source
- EPSS
- 0.18%, higher than 7.6% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- unimportantsource
- Subsystem
- drivers/acpi
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 6.12.75 | 6.12.109 | 5ff385e9403e |
| 6.18.16 | 6.18.50 | 452eb28e0301 |
| 7.0 | 7.2.4 | b48b613073c3 |
| 7.0 | 7.3 | 903308ea40ad |
| 6.19.6 | 0 | 0 |
Debian advisories
| Advisory | Date | Shipped to | Debian |
|---|---|---|---|
| DLA-4817-1 | 2026-10-04 | bookworm 6.12.111-1~deb12u1 | tracker |
| DSA-6528-1 | 2026-09-29 | trixie 6.12.111-1 | tracker |
Why the CNA scored it this way
Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source
- AV:LAttack vector, local
- GHES ARM processor CPER sections are consumed on the local host from ACPI APEI notifications (SCI, GSIV, GPIO, SEA, SDEI, NMI, or poll) via ghes_proc()/ghes_proc_in_irq() into ghes_handle_arm_hw_error(); there is no network or radio path. The most severe case is a local ARM server or VM whose firmware delivers a crafted ARM section.
- AC:LAttack complexity, low
- After skipping the cper_sec_proc_arm header, remaining length was reduced by sizeof(pointer) (8) instead of sizeof(*err) (40), over-counting by 32 bytes. A recoverable ARM section with err_info_num large relative to error_data_length then deterministically parses past the section; no race or attacker-uncontrollable layout is required.
- PR:NPrivileges required, none
- ghes_do_proc() and ghes_handle_arm_hw_error() apply no capability or credential check; firmware-first RAS notifications are processed in IRQ, NMI, or kworker context without a host login. Compromised ACPI/SDEI firmware or a BMC-written GHES status block needs no Linux account, matching other firmware-sourced kernel CNA scores.
- UI:NUser interaction, none
- GHES consumes the CPER record automatically on the notification and irq_work path. No victim action such as mounting a filesystem, opening a device node, or confirming a prompt is required.
- S:UScope, unchanged
- The out-of-bounds parse and any memory_failure() side effects remain in the host kernel that handles GHES. This is not a KVM/Xen guest-to-host escape or an IOMMU/DMA boundary bypass.
- C:HConfidentiality impact, high
- The inflated remaining length lets the parser read a cper_arm_err_info object past the CPER section. On the SEA/NMI path the estatus node is allocated to the exact CPER size, so this is a kernel gen_pool/heap out-of-bounds read of adjacent objects, including pointers.
- I:HIntegrity impact, high
- Out-of-bounds err_info fields are interpreted as a processor cache-error record; if type and validation_bits match, ghes_do_memory_failure() poisons err_info->physical_fault_addr taken from adjacent memory. Firmware-controlled neighboring bytes thus yield a kernel integrity primitive via HWPoison of arbitrary PFNs.
- A:HAvailability impact, high
- Reading past an exact-sized ghes_estatus_pool node can hit unmapped memory and oops, as the related ARM GHES parser already did on QEMU. memory_failure() of kernel pages or a large err_info_num walk in IRQ context can panic or hang, and notifications can be repeated.