CVE-2025-38670

What it actually does

Race condition in arm64 cpu_switch_to() and call_on_irq_stack() allows SErrors or Debug Exceptions (or pseudo-NMIs) to interrupt non-atomic stack/SCS pointer updates, resulting in clobbered Shadow Call Stack pointers, mismatched stacks, and subsequent kernel panics via CONFIG_VMAP_STACK or FPAC.

Why it matters to the business

Unpredictable kernel panics on arm64 Linux systems (especially those with CONFIG_ARM64_PSEUDO_NMI) cause system instability, workload disruption, and potential denial of service in containerized or high-density environments; high downstream prevalence of the kernel increases exposure across fleets.

How an attack unfolds

An attacker with local code execution triggers frequent interrupts during task switching or IRQ stack transitions; when CONFIG_ARM64_PSEUDO_NMI is enabled the race becomes practical, corrupting SCS pointers so that tasks return through incorrect stacks and panic the kernel.

How to fix it

Upgrade Linux kernel to 5.10.210 or commit f7e0231eeaa33245c649fac0303cf97209605446; for Chainguard packages upgrade openjdk-21-openj9* to 0.53.0-r0. Rebuild and reboot systems; mask DAIF in the affected assembly paths as shown in the fix.

How to confirm the fix worked

Verify running kernel version >= 5.10.210 and presence of the masking macro in cpu_switch_to and call_on_irq_stack; confirm CONFIG_SHADOW_CALL_STACK and CONFIG_ARM64_PSEUDO_NMI settings; run targeted boot and workload tests that exercise task switching.

Typical attack path

1. Obtain local code execution on affected arm64 Linux host or container
2. Enable or rely on workload that exercises task switching under pseudo-NMI
3. Interrupt cpu_switch_to() or call_on_irq_stack() at the precise non-atomic window
4. Force SCS pointer clobber and trigger return via corrupted stack
5. Cause kernel panic (vmap_stack or FPAC) to achieve denial of service

How to detect it

Search kernel logs and dmesg for panic strings referencing vmap_stack, FPAC, or mismatched SCS pointers during task switching; correlate with high-frequency pseudo-NMI events or container workload spikes on arm64 hosts.

• kernel panic: stack
• vmap allocation
• FPAC exception
• SCS pointer mismatch

What your security team should do

• Prioritize kernel upgrades on all arm64 systems using pseudo-NMI or Shadow Call Stack within the next patch cycle
• Audit container hosts for affected kernel versions and schedule immediate reboots after upgrade
• Enable CONFIG_VMAP_STACK and FPAC where possible to convert silent corruption into detectable panics
• Monitor EPSS trend and re-evaluate if new exploit code appears