Look up another CVE · open CVE-2026-90120 in the interactive tracker
CVE-2026-90120
irqchip/gic-v5: Check get_logical_index() return value in MADT IAFFID parsing
Published 2026-09-17 (31 days ago) by the Linux kernel CNA. Subsystem drivers/irqchip. Debian urgency: unimportant.
What to do, per Debian release
Debian's own status for CVE-2026-90120 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 | not affected | 6.12.113-1 | Nothing to do. trixie never shipped the vulnerable code. |
| 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. |
The vulnerability
What the bug is
In gic_acpi_parse_iaffid() a given MADT GICC entry might not correspond to a logical cpu recognized by the kernel, resulting in the cpu variable initialization to an error value. Currently, the get_logical_index() return value is not checked for failure, which might result in out-of-bounds memory corruption while trying to index a per_cpu variable array. Add a check to evaluate get_logical_index() return value.
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/irqchip/irq-gic-v5-irs.c
- What this is
- IRQCHIP DRIVERSMAINTAINERS section matched on drivers/irqchip/ · linux-kernel@vger.kernel.org · Maintained
Check it on the machine
grep -w CONFIG_ARM_GIC_V5 /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. The build rule could not be established for 2 releases, so nothing is claimed about those.
- bookworm, trixie?
- forky, sidYnot built on amd64/amd64, amd64/cloud-amd64, amd64/rt-amd64, armhf/armmp, armhf/armmp-lpae, loong64/loong64, ppc64el/powerpc64le, ppc64el/powerpc64le-64k, riscv64/riscv64, s390x/s390x
- ?
- not established - no Makefile entry for the affected file
- Y
- built in where it is built at all; some flavours do not build it
Where a release above reads "not established", no build rule for the affected file was found in that release's kernel tree. That is a gap in this lookup, not a finding that the code is absent.
- Build switch
- CONFIG_ARM_GIC_V5
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-17 (31 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.20%, higher than 9.1% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- unimportantsource
- Subsystem
- drivers/irqchip
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 7.0 | 7.2.6 | 6caeb878f809 |
| 7.0 | 7.3 | 328affc639ce |
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
- The triggering bytes are MADT GICC arm_mpidr/iaffid/irs_id fields parsed by gic_acpi_parse_iaffid() from acpi_table_parse_madt() on the init_IRQ()->irqchip_init()->gic_acpi_init()->gicv5_irs_acpi_probe() boot path; they arrive from firmware, a hypervisor ACPI blob, or an initrd MADT override, not from a network protocol message.
- AC:LAttack complexity, low
- A MADT GICC with ACPI_MADT_ENABLED set and an arm_mpidr that acpi_map_gic_cpu_interface() never installed (invalid MPIDR, or cpu_count >= NR_CPUS) makes get_logical_index() return -EINVAL every boot; per_cpu() then uses that error index with no race or attacker-uncontrollable layout.
- PR:NPrivileges required, none
- gic_acpi_parse_iaffid() is an __init MADT walker with no capable() or uid check, invoked from irqchip_init() before userspace; a crafted MADT GICC is consumed automatically, so no Linux account or user-namespace capability is required.
- UI:NUser interaction, none
- arm64 init_IRQ() calls irqchip_init(), which probes the GICv5 IRS MADT entry and walks GICC subtables via gicv5_irs_acpi_init_affinity(); the OOB store happens on that boot parse with no mount, open, or other victim action.
- S:UScope, unchanged
- The stores go to per_cpu(cpu_iaffid, cpu) and per_cpu(per_cpu_irs_data, cpu) in the host GICv5 IRS affinity setup; this stays inside the kernel's authority and is not a KVM guest-to-host, IOMMU, or sandbox crossing.
- C:HConfidentiality impact, high
- Using get_logical_index()'s -EINVAL as the cpu argument to per_cpu() is an out-of-bounds write of gicc->iaffid and a kmalloc'd gicv5_irs_chip_data pointer through __per_cpu_offset[]; that kernel memory corruption can be leveraged for information disclosure.
- I:HIntegrity impact, high
- gic_acpi_parse_iaffid() writes gicc->iaffid, valid=true, and current_irs_data via per_cpu(cpu_iaffid/per_cpu_irs_data, cpu) when cpu is -EINVAL, corrupting memory outside the per-cpu arrays with attacker-influenced MADT data and a kernel heap pointer.
- A:HAvailability impact, high
- __per_cpu_offset[-EINVAL] plus the subsequent per_cpu stores during gicv5_irs_acpi_probe() can target unmapped or live kernel data and oops/panic in init_IRQ() while bringing up GICv5, which is a full kernel availability loss.