CVE-2025-38670
Unknown Unknown - Not Provided
BaseFortify

Publication date: 2025-08-22

Last updated on: 2025-11-03

Assigner: kernel.org

Description
In the Linux kernel, the following vulnerability has been resolved: arm64/entry: Mask DAIF in cpu_switch_to(), call_on_irq_stack() `cpu_switch_to()` and `call_on_irq_stack()` manipulate SP to change to different stacks along with the Shadow Call Stack if it is enabled. Those two stack changes cannot be done atomically and both functions can be interrupted by SErrors or Debug Exceptions which, though unlikely, is very much broken : if interrupted, we can end up with mismatched stacks and Shadow Call Stack leading to clobbered stacks. In `cpu_switch_to()`, it can happen when SP_EL0 points to the new task, but x18 stills points to the old task's SCS. When the interrupt handler tries to save the task's SCS pointer, it will save the old task SCS pointer (x18) into the new task struct (pointed to by SP_EL0), clobbering it. In `call_on_irq_stack()`, it can happen when switching from the task stack to the IRQ stack and when switching back. In both cases, we can be interrupted when the SCS pointer points to the IRQ SCS, but SP points to the task stack. The nested interrupt handler pushes its return addresses on the IRQ SCS. It then detects that SP points to the task stack, calls `call_on_irq_stack()` and clobbers the task SCS pointer with the IRQ SCS pointer, which it will also use ! This leads to tasks returning to addresses on the wrong SCS, or even on the IRQ SCS, triggering kernel panics via CONFIG_VMAP_STACK or FPAC if enabled. This is possible on a default config, but unlikely. However, when enabling CONFIG_ARM64_PSEUDO_NMI, DAIF is unmasked and instead the GIC is responsible for filtering what interrupts the CPU should receive based on priority. Given the goal of emulating NMIs, pseudo-NMIs can be received by the CPU even in `cpu_switch_to()` and `call_on_irq_stack()`, possibly *very* frequently depending on the system configuration and workload, leading to unpredictable kernel panics. Completely mask DAIF in `cpu_switch_to()` and restore it when returning. Do the same in `call_on_irq_stack()`, but restore and mask around the branch. Mask DAIF even if CONFIG_SHADOW_CALL_STACK is not enabled for consistency of behaviour between all configurations. Introduce and use an assembly macro for saving and masking DAIF, as the existing one saves but only masks IF.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2025-08-22
Last Modified
2025-11-03
Generated
2026-05-07
AI Q&A
2025-08-22
EPSS Evaluated
2026-05-05
NVD
CVE-2025-38670
Affected Vendors & Products
Showing 1 associated CPE
Vendor Product Version / Range
linux linux_kernel 6.1.153-1
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-UNKNOWN
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

This vulnerability occurs in the Linux kernel on arm64 architectures involving the functions cpu_switch_to() and call_on_irq_stack(). These functions switch between different stacks and the Shadow Call Stack (SCS). Because these stack switches are not atomic and can be interrupted by SErrors or Debug Exceptions, it can lead to mismatched stacks and corrupted SCS pointers. This causes tasks to return to incorrect addresses or the IRQ SCS, potentially triggering kernel panics. The issue is more likely when CONFIG_ARM64_PSEUDO_NMI is enabled, allowing frequent pseudo-NMIs that can interrupt these functions and cause unpredictable kernel panics.


How can this vulnerability impact me? :

This vulnerability can cause kernel panics due to corrupted stack pointers and mismatched Shadow Call Stacks. This can lead to system instability, crashes, and unpredictable behavior on affected arm64 Linux systems, especially if CONFIG_ARM64_PSEUDO_NMI is enabled. Such panics can disrupt normal operation and potentially cause data loss or service downtime.


What immediate steps should I take to mitigate this vulnerability?

To mitigate this vulnerability, update the Linux kernel to a version where DAIF masking in cpu_switch_to() and call_on_irq_stack() has been fixed as described. This involves ensuring that DAIF is completely masked during these functions to prevent interrupts that cause stack mismatches and kernel panics. Additionally, verify that CONFIG_ARM64_PSEUDO_NMI and CONFIG_SHADOW_CALL_STACK configurations are properly handled according to the fix. If updating is not immediately possible, consider disabling CONFIG_ARM64_PSEUDO_NMI to reduce the risk of frequent pseudo-NMIs causing the issue.


Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart