CVE-2025-38670: arm64/entry: Mask DAIF in cpu_switch_to(), call_on_irq_stack()
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.
Security readout for executives and security teams
Plain-English summary
CVE-2025-38670 is a Linux kernel arm64 flaw where rare interrupt timing during stack switching can corrupt task or shadow call stack state. The documented outcome is unpredictable kernel panic, especially on systems using CONFIG_ARM64_PSEUDO_NMI. This is mainly an availability and reliability concern, not a documented data theft issue.
Executive priority
Treat this as a targeted platform reliability risk. It is not currently documented as exploited, but affected arm64 systems can suffer kernel panics. Prioritize patching for production Linux arm64 fleets, appliances, and systems using pseudo-NMI configurations.
Technical view
The issue affects arm64 cpu_switch_to() and call_on_irq_stack(), where SP and Shadow Call Stack changes were interruptible. SErrors, debug exceptions, or pseudo-NMIs could observe mismatched task, IRQ, and SCS state, corrupt saved SCS pointers and trigger panics. The fix masks DAIF around these stack transitions.
Likely exposure
Exposure appears limited to Linux arm64 systems running affected kernels or downstream products built from them. Risk is higher where CONFIG_ARM64_PSEUDO_NMI is enabled. The bundle names Linux kernel versions and commits, but package-level and appliance-level impact must be confirmed with vendor advisories.
Exploitation context
The source bundle does not show active exploitation, and KEV is false. The described failure can occur on default configurations but is unlikely. With pseudo-NMIs, interrupt frequency can make the condition more likely depending on system configuration and workload.
Researcher notes
Key evidence is the upstream Linux fix description. The bundle lacks CVSS, CWE, proof of exploitation, and full downstream version mapping. Avoid assuming remote exploitability. Focus validation on arm64 kernel lineage, SCS settings, pseudo-NMI configuration, and whether the DAIF masking fix is present.
Mitigation direction
Apply vendor kernel updates containing the referenced stable fixes.
Prioritize arm64 systems using CONFIG_ARM64_PSEUDO_NMI.
Check Debian LTS and Siemens advisories for downstream package or product mapping.
If no vendor fix is available, request vendor guidance for supported mitigation.
Validation and detection
Inventory Linux arm64 hosts and embedded products.
Record kernel version, build provenance, and CONFIG_ARM64_PSEUDO_NMI status.
Compare installed kernels against vendor advisories and referenced stable commits.
Review crash logs for unexplained arm64 kernel panics during context or IRQ stack activity.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cve · low confidence lookup
CVE-2025-38670 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
0CVSS vectors
3Timeline events
2ADP providers
10Source links
Vulnerability timeline
Timeline events are normalized from CVE metadata, CNA source timelines, ADP timelines, and KEV metadata when present.
CVE reservedCVE Program
The CVE ID was reserved by the assigning CNA.
CVE publishedCVE Program
The CVE record was published.
Aug 22, 2025, 16:03 UTC (UTC+00:00)
CVE updatedCVE Program
The CVE record metadata indicates this as the latest update time.