CVE-2026-93254 in Linux
Summary
by MITRE • 09/24/2026
In the Linux kernel, the following vulnerability has been resolved:
arm64: entry: Avoid unnecessary local_irq_disable() on kernel exit
Currently, when exiting to kernel mode, we attempt involuntary preemption. The preemption logic expects IRQs to be disabled, which is why we call local_irq_disable() before attempting preemption.
However, depending on the context, local_irq_disable() may be unnecessary:
- __el1_irq(), the non-NMI EL1 IRQ path, already has IRQs disabled, so local_irq_disable() is redundant.
- irqentry_exit_to_kernel_mode_preempt() immediately returns when exiting from an NMI-like context, so calling local_irq_disable() beforehand is unnecessary work.
Furthermore, it confuses the pNMI state tracking when we are in a context with interrupts disabled and the GIC_PRIO_PSR_I_SET bit is set in the PMR, leading to a warning when CONFIG_ARM64_DEBUG_PRIORITY_MASKING=y:
WARNING: ./arch/arm64/include/asm/irqflags.h:63 at arm64_exit_to_kernel_mode+0xb8/0xc0, CPU#40: retsnoop/31805 CPU: 40 UID: 0 PID: 31805 Comm: retsnoop Not tainted 7.2.0-rc6-next-20260805 #7 PREEMPTLAZY pstate: 234013c9 (nzCv DAIF +PAN -UAO +TCO +DIT +SSBS BTYPE=--) pc : arm64_exit_to_kernel_mode (arch/arm64/kernel/entry-common.c:63) lr : el1_abort (arch/arm64/kernel/entry-common.c:323) pmr: 000000f0 Call trace: arm64_exit_to_kernel_mode (arch/arm64/kernel/entry-common.c:63) (P) el1_abort (arch/arm64/kernel/entry-common.c:323) el1h_64_sync_handler (arch/arm64/kernel/entry-common.c:449) el1h_64_sync (arch/arm64/kernel/entry.S:589) [...]
Split arm64_exit_to_kernel_mode() into preempt, non-preempt, and dispatch parts so that we can avoid this extra work where it is not needed and avoid breaking the pNMI tracking logic.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/24/2026
The Linux kernel for ARM64 architectures contains a performance optimization flaw within the interrupt entry and exit handling code, specifically in the arm64_exit_to_kernel_mode function. This vulnerability stems from an overly aggressive application of local_irq_disable() calls during the transition back to kernel mode after processing interrupts or exceptions. The preemption logic inherent in the Linux scheduler requires that hardware interrupts be disabled before attempting involuntary preemption checks to ensure atomicity and prevent race conditions where a new interrupt could alter scheduling decisions mid-process. Consequently, developers implemented a blanket call to local_irq_disable() at this stage of execution regardless of the current context state. While this approach guarantees safety against concurrent interrupt interference during preemption attempts, it introduces significant unnecessary overhead in scenarios where interrupts are already disabled or when exiting from non-maskable interrupt contexts that do not require such protection.
The technical flaw manifests primarily in two distinct operational paths within the ARM64 exception handling framework. First, in the standard EL1 IRQ path represented by __el1_irq(), hardware interrupts are inherently disabled upon entry to this handler due to architectural behavior of the Generic Interrupt Controller and processor state management. Therefore, executing local_irq_disable() again is redundant as it performs no functional change but consumes CPU cycles for context saving and restoring interrupt flags unnecessarily. Second, when exiting from NMI-like contexts via irqentry_exit_to_kernel_mode_preempt(), the logic immediately returns without engaging in preemption checks because NMIs are designed to be non-preemptible by design. In these cases, disabling interrupts again is not only wasteful but also disrupts the precise state tracking required for priority-based interrupt masking mechanisms known as pNMI.
This redundant operation leads to a specific debugging warning when CONFIG_ARM64_DEBUG_PRIORITY_MASKING is enabled in the kernel configuration. The system detects an inconsistency where local_irq_disable() is called while interrupts are already disabled and the GIC_PRIO_PSR_I_SET bit remains set in the Priority Mask Register, indicating that interrupt masking state tracking has been violated or confused by the redundant operation. This warning appears during routine operations such as abort handling or other synchronous exceptions processed through el1_abort paths. The presence of this warning indicates a deviation from expected hardware-software interaction protocols regarding interrupt priority management, potentially obscuring more critical issues in debug builds and adding latency to high-frequency exception handlers which can impact real-time performance characteristics of the system.
From an industry standard perspective, this issue aligns with CWE-401 Missing Release of Resource after Effective Lifetime or CWE-756 Missing Correct Explanation of Input Constraints if viewed through the lens of inefficient resource management and state assumption errors. More accurately, it represents a Performance Issue often categorized under CWE-398 Poor Code Design in specific contexts where optimization opportunities are missed due to conservative coding practices. In terms of MITRE ATT&CK mapping, while this is not an exploitable vulnerability for attackers seeking privilege escalation or data exfiltration, it relates to T1496 Resource Hijacking indirectly by contributing to increased CPU utilization and potential latency spikes that could degrade service availability under heavy interrupt loads. The flaw does not compromise confidentiality or integrity but affects the reliability and efficiency of kernel operations.
The operational impact of this vulnerability is primarily related to system performance rather than security breach. By executing unnecessary local_irq_disable() calls, the kernel incurs additional overhead in terms of instruction execution cycles and potential cache effects associated with modifying interrupt flag registers. In high-throughput environments or systems handling frequent interrupts such as network servers or real-time control applications, this inefficiency can accumulate to measurable latency increases. Furthermore, the confusion introduced into pNMI state tracking logic may lead to false positive warnings in debug kernels, complicating troubleshooting efforts for developers and potentially masking other genuine priority masking errors that could theoretically affect interrupt delivery order if left unaddressed in production configurations where such debugging is enabled.
Mitigation of this issue requires applying kernel patches that refactor the arm64_exit_to_kernel_mode function into distinct code paths based on context type. The solution involves splitting the logic to handle preemptible, non-preemptible, and dispatch scenarios separately so that local_irq_disable() is only invoked when strictly necessary for preemption safety. This structural change ensures that redundant operations are skipped in contexts where interrupts are already disabled or where NMI semantics dictate immediate return without further processing. System administrators should ensure their ARM64-based systems are updated with the latest kernel versions containing this fix to restore optimal interrupt handling performance and eliminate spurious debug warnings related to priority masking inconsistencies.