CVE-2025-38670

arm64/entry: Mask DAIF in cpu_switch_to(), call_on_irq_stack()

HIGH
7.1
CVSS Score
Published: August 22, 2025 at 04:03 PM UTC
Updated: August 5, 2026 at 12:44 PM UTC
3 products affected across 3 vendorsLinux KernelDebian LinuxSIMATIC CN 4100

Using Linux by Linux?

Get instant alerts when new vulnerabilities affect Linux - before attackers find them.

Real-time alertsTrack your software stackFree plan available
Severity
HIGH7.1
Exploit prediction
EPSS 0.2%

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.

Affected

Our own answer: ranges merged, affected separated from platform-only, with confidence and review flags.

v ≥ 6.2.155.10.180 ≤ v < 5.10.2105.15.111 ≤ v < 5.15.1906.1.28 ≤ v < 6.1.1496.13 ≤ v < 6.15.96.2.15 ≤ v < 6.36.2.15 ≤ v < 6.6.1016.3 ≤ v < 6.12.416.3 ≤ v < 6.15.96.3 ≤ v < 6.166.3 ≤ v < 6.6.1016.7 ≤ v < 6.12.413f225f29c69c13ce1cbdb1d607a42efeef080056402d2b1d54b7085d0c3bfd01fd50c2701dde64b34403c7b7e5e1ad09a266b6e399fd7bf97931508e5.10.1805.15.11159b37fe52f49955791a460752c37145f1afdcad16.1.286.16 rc16.16 rc26.16 rc36.16 rc46.16 rc56.16 rc66.16 rc76.2.15e47ce4f11e26fa3ea99b09521da8b3ac3a7b578d
Vendor states this is fixed in 0f67015d72627bad72da3c2084352e0aa134416b (fixed)
Vendor states this is fixed in 407047893a64399f2d2390ff35cc6061107d805d (fixed)
Vendor states this is fixed in 708fd522b86d2a9544c34ec6a86fa3fc23336525 (fixed)
Vendor states this is fixed in 9433a5f437b0948d6a2d8a02ad7a42ab7ca27a61 (fixed)
Vendor states this is fixed in a6b0cb523eaa01efe8a3f76ced493ba60674c6e6 (fixed)
Vendor states this is fixed in d42e6c20de6192f8e4ab4cf10be8c694ef27e8cb (fixed)
Vendor states this is fixed in f7e0231eeaa33245c649fac0303cf97209605446 (fixed)
Vendor states this is fixed in 5.10.210 (unaffected)
Vendor states this is fixed in 5.15.190 (unaffected)
Vendor states this is fixed in 6.1.149 (unaffected)
Vendor states this is fixed in 6.12.41 (unaffected)
Vendor states this is fixed in 6.15.9 (unaffected)
Vendor states this is fixed in 6.16 (unaffected)
Vendor states this is fixed in 6.3 (unaffected)
Vendor states this is fixed in 6.6.101 (unaffected)
v < V5.0
Affected range stops below V5.0, so it looks safe — our inference, not a vendor statement

References (9)

Patch
Source: 416baaa9-dc9f-4396-8d5f-8c081fb06d67
https://git.kernel.org/stable/c/0f67015d72627bad72da3c2084352e0aa134416b
Patch
Source: 416baaa9-dc9f-4396-8d5f-8c081fb06d67
https://git.kernel.org/stable/c/407047893a64399f2d2390ff35cc6061107d805d
Patch
Source: 416baaa9-dc9f-4396-8d5f-8c081fb06d67
https://git.kernel.org/stable/c/708fd522b86d2a9544c34ec6a86fa3fc23336525
Patch
Source: 416baaa9-dc9f-4396-8d5f-8c081fb06d67
https://git.kernel.org/stable/c/9433a5f437b0948d6a2d8a02ad7a42ab7ca27a61
Patch
Source: 416baaa9-dc9f-4396-8d5f-8c081fb06d67
https://git.kernel.org/stable/c/a6b0cb523eaa01efe8a3f76ced493ba60674c6e6
Patch
Source: 416baaa9-dc9f-4396-8d5f-8c081fb06d67
https://git.kernel.org/stable/c/d42e6c20de6192f8e4ab4cf10be8c694ef27e8cb
Third Party Advisory
Source: af854a3a-2127-422b-91ae-364da2661108
https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html

CVSS

Attack Vector
LOCAL
Complexity
LOW
Privileges
LOW
User Interaction
NONE
Scope
UNCHANGED
Confidentiality
HIGH
Integrity
NONE
Availability
HIGH
Vector?

Quick Info

StatusMODIFIED
CWE
CWE-668

Get alerted

Stop reading CVE feeds looking for your own stack

Track the products you run and VulnTracker tells you when a new CVE affects them — with what is known about fixing it, and nothing about the rest.

Free plan, no card