CVE-2026-90120 in Linux
Summary
by MITRE • 09/17/2026
In the Linux kernel, the following vulnerability has been resolved:
irqchip/gic-v5: Check get_logical_index() return value in MADT IAFFID parsing
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.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 09/17/2026
The Linux kernel's interrupt controller driver for ARM Generic Interrupt Controller version five contains a critical logic flaw within the ACPI MADT IAFFID parsing routine that can lead to severe memory safety violations. The function gic_acpi_parse_iaffid is responsible for processing Interrupt Affinity structures from the Multiple APIC Description Table, which describes how interrupts are associated with specific logical processors in an ACPI-based system. During this process, the driver attempts to map hardware interrupt identifiers to kernel-internal logical CPU indices using the get_logical_index helper function. This mapping is essential because subsequent operations rely on these indices to access per-CPU data structures that store state information relevant to each processor core.
The root cause of this vulnerability lies in the absence of a validation check for the return value of get_logical_index(). Under normal circumstances, if a MADT entry corresponds to an active and recognized logical CPU, the function returns a valid non-negative index. However, when the hardware configuration includes entries that do not correspond to any currently initialized or recognized logical CPU by the kernel, get_logical_index() fails and typically returns a negative error code such as -EINVAL or similar. Because this return value is not inspected for failure conditions before being used as an array subscript, the application proceeds with an invalid index. In C programming, using a negative integer as an array index results in accessing memory locations preceding the start of the intended buffer, which constitutes an out-of-bounds read operation.
This flaw directly facilitates CWE-125, Out-of-Bounds Read, and potentially CWE-787, Out-of-Bounds Write if subsequent logic attempts to write data based on this corrupted index after further processing errors occur. The immediate operational impact is the corruption of kernel memory space outside the bounds of the per_cpu variable array. Such out-of-bounds access can lead to unpredictable system behavior, including silent data corruption, crashes leading to a denial of service through kernel panic or oops messages, and in more complex scenarios involving specific memory layouts, it may allow an attacker with local physical access or via ACPI table manipulation to read sensitive kernel memory contents or potentially influence control flow if the corrupted values are later used for pointer arithmetic. This aligns with ATT&CK technique T1059, Command and Scripting Interpreter, as malicious actors could theoretically leverage such instability in conjunction with other vulnerabilities to achieve arbitrary code execution during boot sequences where ACPI tables are parsed early in the initialization phase.
Mitigation strategies primarily involve applying vendor-provided kernel patches that introduce explicit validation logic within gic_acpi_parse_iaffid(). The fix requires checking whether get_logical_index() returns a negative value indicating failure, and if so, skipping the processing of that specific MADT entry or logging an error to prevent further execution with invalid indices. System administrators should ensure their systems are updated with the latest stable kernel versions containing this patch. Additionally, since ACPI tables can be modified by physical attackers or through virtualization layers in cloud environments, it is advisable to validate hardware configuration integrity and monitor system logs for early signs of parsing errors during boot time that might indicate attempts to exploit similar uninitialized state issues.