linux-cve-announce - CVE-2025-38670: arm64/entry: Mask DAIF in cpu_switch_to(), call_on_irq

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <2025082201-CVE-2025-38670-0dcc@gregkh>
Date: Fri, 22 Aug 2025 18:03:07 +0200
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: linux-cve-announce@...r.kernel.org
Cc: Greg Kroah-Hartman <gregkh@...nel.org>
Subject: CVE-2025-38670: arm64/entry: Mask DAIF in cpu_switch_to(), call_on_irq_stack()

From: Greg Kroah-Hartman <gregkh@...nel.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.

The Linux kernel CVE team has assigned CVE-2025-38670 to this issue.

Affected and fixed versions
===========================

	Issue introduced in 6.3 with commit 59b37fe52f49955791a460752c37145f1afdcad1 and fixed in 6.6.101 with commit 9433a5f437b0948d6a2d8a02ad7a42ab7ca27a61
	Issue introduced in 6.3 with commit 59b37fe52f49955791a460752c37145f1afdcad1 and fixed in 6.12.41 with commit 708fd522b86d2a9544c34ec6a86fa3fc23336525
	Issue introduced in 6.3 with commit 59b37fe52f49955791a460752c37145f1afdcad1 and fixed in 6.15.9 with commit 0f67015d72627bad72da3c2084352e0aa134416b
	Issue introduced in 6.3 with commit 59b37fe52f49955791a460752c37145f1afdcad1 and fixed in 6.16 with commit d42e6c20de6192f8e4ab4cf10be8c694ef27e8cb
	Issue introduced in 5.15.111 with commit 402d2b1d54b7085d0c3bfd01fd50c2701dde64b3
	Issue introduced in 6.1.28 with commit 4403c7b7e5e1ad09a266b6e399fd7bf97931508e
	Issue introduced in 6.2.15 with commit e47ce4f11e26fa3ea99b09521da8b3ac3a7b578d

Please see https://www.kernel.org for a full list of currently supported
kernel versions by the kernel community.

Unaffected versions might change over time as fixes are backported to
older supported kernel versions.  The official CVE entry at
	https://cve.org/CVERecord/?id=CVE-2025-38670
will be updated if fixes are backported, please check that for the most
up to date information about this issue.

Affected files
==============

The file(s) affected by this issue are:
	arch/arm64/include/asm/assembler.h
	arch/arm64/kernel/entry.S

Mitigation
==========

The Linux kernel CVE team recommends that you update to the latest
stable kernel version for this, and many other bugfixes.  Individual
changes are never tested alone, but rather are part of a larger kernel
release.  Cherry-picking individual commits is not recommended or
supported by the Linux kernel community at all.  If however, updating to
the latest release is impossible, the individual changes to resolve this
issue can be found at these commits:
	https://git.kernel.org/stable/c/9433a5f437b0948d6a2d8a02ad7a42ab7ca27a61
	https://git.kernel.org/stable/c/708fd522b86d2a9544c34ec6a86fa3fc23336525
	https://git.kernel.org/stable/c/0f67015d72627bad72da3c2084352e0aa134416b
	https://git.kernel.org/stable/c/d42e6c20de6192f8e4ab4cf10be8c694ef27e8cb