UBUNTU-CVE-2025-38670
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.
02 / AFFECTED SOFTWARE
Affected packages
11 explicit affected versions
75 explicit affected versions
50 explicit affected versions
6 explicit affected versions
12 explicit affected versions
19 explicit affected versions
6 explicit affected versions
85 explicit affected versions
24 explicit affected versions
70 explicit affected versions
70 explicit affected versions
76 explicit affected versions
65 explicit affected versions
10 explicit affected versions
28 explicit affected versions
26 explicit affected versions
77 explicit affected versions
7 explicit affected versions
74 explicit affected versions
32 explicit affected versions
13 explicit affected versions
35 explicit affected versions
35 explicit affected versions
37 explicit affected versions
35 explicit affected versions
18 explicit affected versions
32 explicit affected versions
64 explicit affected versions
37 explicit affected versions
13 explicit affected versions
4 explicit affected versions
23 explicit affected versions
43 explicit affected versions
1 explicit affected versions
21 explicit affected versions
9 explicit affected versions
16 explicit affected versions
10 explicit affected versions
39 explicit affected versions
8 explicit affected versions
7 explicit affected versions
1 explicit affected versions
12 explicit affected versions
9 explicit affected versions
7 explicit affected versions
7 explicit affected versions
9 explicit affected versions
12 explicit affected versions
12 explicit affected versions
32 explicit affected versions
31 explicit affected versions
12 explicit affected versions
14 explicit affected versions
10 explicit affected versions
29 explicit affected versions
13 explicit affected versions
10 explicit affected versions
82 explicit affected versions
32 explicit affected versions
32 explicit affected versions
77 explicit affected versions
40 explicit affected versions
33 explicit affected versions
23 explicit affected versions
46 explicit affected versions
10 explicit affected versions
11 explicit affected versions
10 explicit affected versions
11 explicit affected versions
5 explicit affected versions
11 explicit affected versions
23 explicit affected versions
25 explicit affected versions
10 explicit affected versions
37 explicit affected versions
10 explicit affected versions
13 explicit affected versions
31 explicit affected versions
3 explicit affected versions
10 explicit affected versions
9 explicit affected versions
52 explicit affected versions
26 explicit affected versions
3 explicit affected versions
13 explicit affected versions
24 explicit affected versions
12 explicit affected versions
7 explicit affected versions
12 explicit affected versions
4 explicit affected versions
62 explicit affected versions
78 explicit affected versions
10 explicit affected versions
26 explicit affected versions
31 explicit affected versions
1 explicit affected versions
54 explicit affected versions
26 explicit affected versions
38 explicit affected versions
9 explicit affected versions
13 explicit affected versions
37 explicit affected versions
16 explicit affected versions
76 explicit affected versions
41 explicit affected versions
3 explicit affected versions
7 explicit affected versions
2 explicit affected versions
51 explicit affected versions
18 explicit affected versions
33 explicit affected versions
12 explicit affected versions
64 explicit affected versions
65 explicit affected versions
27 explicit affected versions
51 explicit affected versions
34 explicit affected versions
8 explicit affected versions
42 explicit affected versions
5 explicit affected versions
3 explicit affected versions
8 explicit affected versions
10 explicit affected versions
7 explicit affected versions
37 explicit affected versions
13 explicit affected versions
13 explicit affected versions
7 explicit affected versions
8 explicit affected versions
10 explicit affected versions
12 explicit affected versions
7 explicit affected versions
25 explicit affected versions
44 explicit affected versions
16 explicit affected versions
3 explicit affected versions
13 explicit affected versions
26 explicit affected versions
45 explicit affected versions
37 explicit affected versions
42 explicit affected versions
14 explicit affected versions
38 explicit affected versions
9 explicit affected versions
11 explicit affected versions
30 explicit affected versions
13 explicit affected versions
78 explicit affected versions
8 explicit affected versions
7 explicit affected versions
4 explicit affected versions
67 explicit affected versions
1 explicit affected versions
1 explicit affected versions
76 explicit affected versions
67 explicit affected versions
66 explicit affected versions
13 explicit affected versions
43 explicit affected versions
10 explicit affected versions
8 explicit affected versions
36 explicit affected versions
14 explicit affected versions
4 explicit affected versions
78 explicit affected versions
11 explicit affected versions
1 explicit affected versions
10 explicit affected versions
30 explicit affected versions
66 explicit affected versions
03 / CONNECTIONS
Connected vulnerabilities
04 / EVIDENCE
Source records
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.
05 / REFERENCES
Further evidence
- https://git.kernel.org/linus/d42e6c20de6192f8e4ab4cf10be8c694ef27e8cb
- https://git.kernel.org/stable/c/0f67015d72627bad72da3c2084352e0aa134416b
- https://git.kernel.org/stable/c/708fd522b86d2a9544c34ec6a86fa3fc23336525
- https://git.kernel.org/stable/c/9433a5f437b0948d6a2d8a02ad7a42ab7ca27a61
- https://git.kernel.org/stable/c/d42e6c20de6192f8e4ab4cf10be8c694ef27e8cb
- https://ubuntu.com/security/CVE-2025-38670
- https://ubuntu.com/security/notices/USN-7879-1
- https://ubuntu.com/security/notices/USN-7879-2
- https://ubuntu.com/security/notices/USN-7879-3
- https://ubuntu.com/security/notices/USN-7879-4
- https://ubuntu.com/security/notices/USN-7880-1
- https://ubuntu.com/security/notices/USN-7909-1
- https://ubuntu.com/security/notices/USN-7909-2
- https://ubuntu.com/security/notices/USN-7909-3
- https://ubuntu.com/security/notices/USN-7909-4
- https://ubuntu.com/security/notices/USN-7909-5
- https://ubuntu.com/security/notices/USN-7910-1
- https://ubuntu.com/security/notices/USN-7910-2
- https://ubuntu.com/security/notices/USN-7933-1
- https://ubuntu.com/security/notices/USN-7934-1
- https://ubuntu.com/security/notices/USN-7938-1
- https://ubuntu.com/security/notices/USN-8028-1
- https://ubuntu.com/security/notices/USN-8028-2
- https://ubuntu.com/security/notices/USN-8028-3
- https://ubuntu.com/security/notices/USN-8028-4
- https://ubuntu.com/security/notices/USN-8028-5
- https://ubuntu.com/security/notices/USN-8028-6
- https://ubuntu.com/security/notices/USN-8028-7
- https://ubuntu.com/security/notices/USN-8028-8
- https://ubuntu.com/security/notices/USN-8031-1
- https://ubuntu.com/security/notices/USN-8031-2
- https://ubuntu.com/security/notices/USN-8031-3
- https://ubuntu.com/security/notices/USN-8052-1
- https://ubuntu.com/security/notices/USN-8052-2
- https://ubuntu.com/security/notices/USN-8074-1
- https://ubuntu.com/security/notices/USN-8074-2
- https://ubuntu.com/security/notices/USN-8126-1
- https://www.cve.org/CVERecord?id=CVE-2025-38670