CVE-2025-38670: arm64/entry: Mask DAIF in cpu_switch_to(), call_on_irq_stack()

Published Aug 22, 2025
·
Updated

In the Linux kernel, the following vulnerability has been resolved:

arm64/entry: Mask DAIF in cpuswitchto(), callonirqstack()

cpuswitchto() and callonirqstack() 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 cpuswitchto(), it can happen when SPEL0 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 SPEL0), clobbering it.

In callonirqstack(), 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 callonirqstack() 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 CONFIGVMAPSTACK or FPAC if enabled.

This is possible on a default config, but unlikely. However, when enabling CONFIGARM64PSEUDONMI, 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 cpuswitchto() and callonirqstack(), possibly very frequently depending on the system configuration and workload, leading to unpredictable kernel panics.

Completely mask DAIF in cpuswitchto() and restore it when returning. Do the same in callonirqstack(), but restore and mask around the branch. Mask DAIF even if CONFIGSHADOWCALLSTACK 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.

Affected Software

15 affected components
Linux Linux kernel<main
Linux Linux kernel>=5.10.180<5.10.210
Linux Linux kernel>=5.15.111<5.15.190
Linux Linux kernel>=6.1.28<6.1.149
Linux Linux kernel>=6.2.15<6.6.101
Linux Linux kernel>=6.7<6.12.41
Linux Linux kernel>=6.13<6.15.9
Linux Linux kernel=6.16-rc1
Linux Linux kernel=6.16-rc2
Linux Linux kernel=6.16-rc3
Linux Linux kernel=6.16-rc4
Linux Linux kernel=6.16-rc5
Linux Linux kernel=6.16-rc6
Linux Linux kernel=6.16-rc7
Debian Debian Linux=11.0

Event History

Aug 22, 2025
CVE Published
via MITRE·04:03 PM
Data Sourced
via MITRE·04:03 PM
DescriptionSeverity
Data Sourced
via NVD·04:15 PM
RemedyDescriptionSeverityWeaknessAffected Software

Frequently Asked Questions

1

What is the severity of CVE-2025-38670?

CVE-2025-38670 has a moderate severity rating due to potential impacts on system stability and security in the Linux kernel.

2

How do I fix CVE-2025-38670?

To fix CVE-2025-38670, upgrade to the latest patched version of the Linux kernel that addresses this vulnerability.

3

What versions of the Linux kernel are affected by CVE-2025-38670?

CVE-2025-38670 affects multiple versions of the Linux kernel prior to the release of the security patches.

4

What are the risks associated with CVE-2025-38670?

The risks associated with CVE-2025-38670 include potential denial of service and exploitation of stack manipulation vulnerabilities.

5

Is there a workaround for CVE-2025-38670?

There are no known workarounds for CVE-2025-38670; the recommended solution is to apply the kernel update.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203