CVE-2026-90121 in Linux
Summary
by MITRE • 09/17/2026
In the Linux kernel, the following vulnerability has been resolved:
irqchip/gic-v5: Clear per-CPU IRS data on teardown
IRS affinity setup publishes an IRS pointer and IAFFID state in the per-CPU data before the remaining IRS initialization can fail. The error path then frees the IRS data without clearing that published state, leaving CPUs associated with freed memory.
On initialization failure and normal IRS teardown, clear the per-CPU IRS association by removing the stale pointer to irs_data. Also invalidate the per-CPU IAFFID state for any CPUs that were tied to the IRS before it was freed.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/17/2026
The vulnerability identified in the Linux kernel's GIC-v5 interrupt controller driver represents a critical race condition and resource management flaw within the Interrupt Remapping Service (IRS) initialization and teardown sequences. This issue stems from an improper handling of per-CPU data structures during error paths, specifically when IRS setup fails after partial completion or during normal system shutdown procedures. The core technical flaw lies in the sequence of operations performed by the irqchip/gic-v5 driver. During the affinity setup phase, the kernel publishes a pointer to the IRS data structure and sets the Interrupt Affinity ID (IAFFID) state within per-CPU memory regions before all necessary initialization steps are fully completed or verified. This early publication is intended to make the resource available for immediate use by other subsystems that may depend on it. However, if subsequent initialization steps fail due to hardware errors, configuration mismatches, or resource exhaustion, the error handling routine proceeds to free the allocated IRS memory without first clearing these published references in the per-CPU data structures.
This oversight results in a classic dangling pointer scenario where CPUs retain stale pointers to freed memory regions and invalid affinity identifiers. When subsequent operations attempt to access this IRS data through the cached per-CPU variables, they dereference addresses that no longer belong to valid kernel allocations. Depending on the timing of memory reuse by other subsystems, this can lead to severe consequences ranging from silent data corruption to immediate system crashes via general protection faults or null pointer exceptions. The vulnerability is particularly insidious because it does not require specific user interaction or external triggers; it manifests during standard driver initialization failures or routine teardown processes, making it a reliable vector for instability in environments where hardware configuration changes frequently occur or when dealing with marginal hardware compatibility scenarios.
From an industry standards perspective, this flaw aligns closely with CWE-416: Use After Free, as the system continues to utilize memory references after they have been deallocated. Additionally, because the issue involves improper resource cleanup and state management during error handling paths, it also reflects aspects of CWE-755: Improper Handling of Exceptional Conditions. The failure to clear per-CPU state variables before freeing associated resources violates fundamental principles of safe memory management in kernel-space programming. In terms of attack surface classification under the MITRE ATT&CK framework, while this is primarily a stability and reliability issue rather than an exploitable privilege escalation vector by itself, it could potentially be leveraged as part of a broader exploitation chain to achieve Denial of Service (T1499) or, in rare cases involving specific memory layout conditions, arbitrary code execution if the freed memory is reallocated with attacker-controlled data and subsequently accessed.
The operational impact of this vulnerability extends beyond simple system crashes. In virtualized environments where GIC-v5 emulations are heavily utilized, such as KVM or other hypervisors running Linux guests, instability in the interrupt controller driver can lead to guest OS panics that affect host stability if not properly isolated. Furthermore, for systems relying on high-availability configurations, unexpected reboots caused by these race conditions during boot sequences or module unloads can disrupt service continuity and compromise system integrity metrics. The lack of proper state invalidation means that even after the driver is unloaded or reset, residual per-CPU data may persist in memory until those specific CPU cores are repurposed for other tasks, potentially causing delayed failures that are difficult to diagnose through standard logging mechanisms since the root cause occurred during an earlier initialization phase.
Mitigation strategies primarily involve applying kernel patches that address this specific logic error within the irqchip/gic-v5 subsystem. System administrators should ensure their Linux kernels are updated to versions where this teardown sequence has been corrected to explicitly clear per-CPU IRS associations and invalidate IAFFID states before any memory is released. For environments unable to update immediately, disabling dynamic interrupt remapping features or configuring static IRQ affinities that do not rely on the problematic initialization path may serve as a temporary workaround, although this reduces flexibility in resource management. Long-term remediation requires rigorous code review practices focused on error handling paths in kernel drivers, ensuring that any published state is reverted before resources are freed to prevent dangling references and maintain memory safety guarantees across all execution branches including failure modes.