CVE-2026-92522

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 IO_APIC subtable headers (hdr->length/type) and _MAT buffers parsed by parse_madt_ioapic_entry()/parse_mat_ioapic_entry() from acpi_get_ioapic_id(), called by acpi_register_ioapic() via handle_ioapic_add() during pcibios_assign_resources() and acpi_pci_root_add() hotadd. They arrive from firmware or a hypervisor ACPI blob, not a network protocol message.

AC:LAttack complexity, low

A MADT subtable with length 0 makes parse_madt_ioapic_entry() add hdr->length each iteration and never exit. A type-ACPI_MADT_TYPE_IO_APIC record whose length is only sizeof(acpi_subtable_header) makes get_ioapic_id() read the 12-byte acpi_madt_io_apic body past the record. Both are deterministic with no race.

PR:NPrivileges required, none

acpi_get_ioapic_id() runs from fs_initcall(pcibios_assign_resources) through pci_assign_unassigned_resources()->acpi_ioapic_add() with no capable() or credential check. A crafted MADT from get_madt_table() or a _MAT buffer from acpi_evaluate_object() is consumed automatically; no Linux account or user-namespace capability is required.

UI:NUser interaction, none

After the MADT/_MAT is in place, pcibios_assign_resources() and acpi_pci_root_add() (hotadd when system_state==SYSTEM_RUNNING) walk ACPI0009/ACPI000A devices in handle_ioapic_add() and call acpi_register_ioapic() with no victim mount, open, or other interactive action.

S:UScope, unchanged

get_ioapic_id() over-reads and parse_madt_ioapic_entry() hangs inside the same kernel that owns the MADT mapping and the _MAT ACPI buffer. This is not a KVM guest-to-host escape, IOMMU/DMA bypass, or sandbox crossing.

C:LConfidentiality impact, low

get_ioapic_id() reads ioapic->id, ioapic->address, and ioapic->global_irq_base from a 12-byte acpi_madt_io_apic while only a 2-byte acpi_subtable_header was shown to fit in the MADT range or _MAT obj->buffer.length. That is a strictly bounded few-byte over-read, not an arbitrary kernel read.

I:LIntegrity impact, low

On a gsi_base match, get_ioapic_id() writes the over-read ioapic->id into *ioapic_id, and acpi_register_ioapic() passes it to mp_register_ioapic() which stores it in ioapics[].mp_config.apicid. That is limited IRQ metadata modification, not an out-of-bounds write or control-flow hijack primitive.

A:HAvailability impact, high

parse_madt_ioapic_entry() infinite-loops when hdr->length is 0, hanging fs_initcall(pcibios_assign_resources) or PCI-root hotplug. get_ioapic_id()'s 12-byte read past a MADT mapping or _MAT heap buffer can also oops if the following bytes are unmapped.