CVE-2025-38670 — linux / linux_kernel
Exposure of Resource to Wrong SphereIn 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.
| Software | From | Fixed in |
|---|---|---|
| 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 | 6.16-rc1.x |
| linux / linux_kernel | 6.16-rc2 | 6.16-rc2.x |
| linux / linux_kernel | 6.16-rc3 | 6.16-rc3.x |
| linux / linux_kernel | 6.16-rc4 | 6.16-rc4.x |
| linux / linux_kernel | 6.16-rc5 | 6.16-rc5.x |
| linux / linux_kernel | 6.16-rc6 | 6.16-rc6.x |
| linux / linux_kernel | 6.16-rc7 | 6.16-rc7.x |
| debian / debian_linux | 11.0 | 11.0.x |
- https://cert-portal.siemens.com/productcert/html/ssa-032379.html
- https://git.kernel.org/stable/c/0f67015d72627bad72da3c2084352e0aa134416b
- https://git.kernel.org/stable/c/407047893a64399f2d2390ff35cc6061107d805d
- https://git.kernel.org/stable/c/708fd522b86d2a9544c34ec6a86fa3fc23336525
- https://git.kernel.org/stable/c/9433a5f437b0948d6a2d8a02ad7a42ab7ca27a61
- https://git.kernel.org/stable/c/a6b0cb523eaa01efe8a3f76ced493ba60674c6e6
- https://git.kernel.org/stable/c/d42e6c20de6192f8e4ab4cf10be8c694ef27e8cb
- https://git.kernel.org/stable/c/f7e0231eeaa33245c649fac0303cf97209605446
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Deep Security Visibility Without the Complexity
SynScan provides clear, real-time security insights so you can monitor your attack surface, spot risks early, and act fast—without extra complexity.
- No setup fees
- 5-min deployment
- Cancel anytime
Frequently Asked Questions
A security vulnerability is a weakness in software, hardware, or configuration that can be exploited to compromise confidentiality, integrity, or availability. Many vulnerabilities are tracked as CVEs (Common Vulnerabilities and Exposures), which provide a standardized identifier so teams can coordinate patching, mitigation, and risk assessment across tools and vendors.
CVSS (Common Vulnerability Scoring System) estimates technical severity, but it doesn't automatically equal business risk. Prioritize using context like internet exposure, affected asset criticality, known exploitation (proof-of-concept or in-the-wild), and whether compensating controls exist. A "Medium" CVSS on an exposed, production system can be more urgent than a "Critical" on an isolated, non-production host.
A vulnerability is the underlying weakness. An exploit is the method or code used to take advantage of it. A zero-day is a vulnerability that is unknown to the vendor or has no publicly available fix when attackers begin using it. In practice, risk increases sharply when exploitation becomes reliable or widespread.
Recurring findings usually come from incomplete Asset Discovery, inconsistent patch management, inherited images, and configuration drift. In modern environments, you also need to watch the software supply chain: dependencies, containers, build pipelines, and third-party services can reintroduce the same weakness even after you patch a single host. Unknown or unmanaged assets (often called Shadow IT) are a common reason the same issues resurface.
Use a simple, repeatable triage model: focus first on externally exposed assets, high-value systems (identity, VPN, email, production), vulnerabilities with known exploits, and issues that enable remote code execution or privilege escalation. Then enforce patch SLAs and track progress using consistent metrics so remediation is steady, not reactive.
SynScan combines attack surface monitoring and continuous security auditing to keep your inventory current, flag high-impact vulnerabilities early, and help you turn raw findings into a practical remediation plan.