CVE-2025-38320: Linux Kernel Use-After-Free Vulnerability

CVE-2025-38320 Overview

CVE-2025-38320 is a stack out-of-bounds read vulnerability in the Linux kernel's arm64 ptrace subsystem. The flaw resides in regs_get_kernel_stack_nth(), where Kernel Address Sanitizer (KASAN) reports invalid reads originating from kprobe-based tracing paths. The issue was triggered through kprobe_trace_func -> process_fetch_insn -> regs_get_kernel_stack_nth+0xa8/0xc8 during clone syscall handling. The condition is related to gcc compiler behavior producing stack layouts that KASAN considers out of bounds, even though addr has been verified to reside on the stack. A similar defect was previously fixed on s390 in commit d93a855c31b7. The fix wraps the dereference in READ_ONCE_NOCHECK() to suppress the KASAN check [CWE-125].

Critical Impact
A local, low-privileged attacker able to invoke kprobe tracing on arm64 systems can trigger stack out-of-bounds reads in kernel memory, resulting in kernel information disclosure or denial of service via kernel panic on KASAN-enabled builds.

Affected Products

Linux Kernel (multiple stable branches up to and including 6.16-rc2)
Linux Kernel 6.16:rc1 and 6.16:rc2 pre-release builds
Debian Linux 11.0 (addressed in Debian LTS announcements)

Discovery Timeline

2025-07-10 - CVE-2025-38320 published to NVD
2026-06-17 - Last updated in NVD database

Technical Details for CVE-2025-38320

Vulnerability Analysis

The vulnerability lives in arch/arm64/kernel/ptrace.c in the helper regs_get_kernel_stack_nth(). This function returns the nth value from a kernel stack frame and is called by kprobe fetch instructions when tracing kernel function arguments. On arm64, kprobe tracing of __se_sys_clone triggers a KASAN stack-out-of-bounds report at offset 0xa8/0xc8 inside the helper.

The KASAN report shows a size 8 read at ffff800089277c10, which sits at offset 0 of the frame for __se_sys_clone+0x0/0x138. The frame contains one tracked object, args at bytes [48, 184), and the read falls into the redzone bytes marked f1 f1 f1 f1. This indicates that the compiler laid out the stack such that a legitimate register-save area is placed inside a KASAN-instrumented redzone.

The issue is not memory corruption but an instrumentation false positive. However, on KASAN-enabled kernels the report converts to a panic when panic_on_warn is configured, producing a local denial of service. On non-KASAN production kernels the same access reads adjacent stack bytes and can surface uninitialized kernel data through the kprobe event stream to userspace.

Root Cause

The root cause is a mismatch between what regs_get_kernel_stack_nth() treats as valid and what KASAN considers valid. The function has already verified that addr points inside the current task stack. However, gcc-generated frame layouts on arm64 place the target byte inside a KASAN redzone rather than a tracked object. KASAN's compiler-inserted __asan_load8 check flags the access as out-of-bounds. The same class of defect was previously resolved on s390 by commit d93a855c31b7.

Attack Vector

Exploitation requires local access and the ability to create kprobe events, typically through /sys/kernel/tracing/kprobe_events or the perf kprobe PMU. An attacker with CAP_SYS_ADMIN or equivalent tracing privileges registers a kprobe on an arm64 syscall entry, defines a fetch argument that reads a stack-relative offset, and triggers the traced syscall. The read passes the runtime stack-range check but violates KASAN shadow state, producing either a report on debug kernels or a raw disclosure on release kernels. The vulnerability manifests during normal kprobe dispatch through kprobe_breakpoint_handler and call_break_hook. See the Kernel Git Commit 92750bf for the applied fix, which replaces the direct dereference with READ_ONCE_NOCHECK(*addr) to bypass KASAN instrumentation for this verified-safe access.

Detection Methods for CVE-2025-38320

Indicators of Compromise

Kernel log entries containing BUG: KASAN: stack-out-of-bounds in regs_get_kernel_stack_nth on arm64 hosts.
Unexpected kprobe registrations targeting syscall entry points such as __arm64_sys_clone or __se_sys_clone.
Local users writing to /sys/kernel/tracing/kprobe_events with stack-fetch arguments ($stack0, $stackN).

Detection Strategies

Audit kernel ring buffer output for KASAN reports referencing regs_get_kernel_stack_nth, process_fetch_insn, or kprobe_dispatcher.
Monitor perf_event_open syscalls with type=PERF_TYPE_TRACEPOINT and dynamic kprobe creation by non-root or privileged tracing groups.
Baseline expected users of /sys/kernel/tracing and alert on out-of-baseline writes to kprobe_events or uprobe_events.

Monitoring Recommendations

Ingest dmesg and /var/log/kern.log into your SIEM and create rules for KASAN out-of-bounds strings tied to ptrace or kprobe symbols.
Track kernel package versions across the arm64 fleet and flag hosts still running unpatched 6.x branches referenced in the Kernel Git Commits.
Alert on processes with CAP_SYS_ADMIN or CAP_PERFMON performing tracing operations outside change windows.

How to Mitigate CVE-2025-38320

Immediate Actions Required

Apply the upstream Linux kernel fix that introduces READ_ONCE_NOCHECK() in regs_get_kernel_stack_nth() and reboot affected arm64 hosts.
On Debian systems, install the kernel updates referenced in Debian LTS Announcement #7 and Debian LTS Announcement #8.
Restrict CAP_SYS_ADMIN and CAP_PERFMON and remove tracing group membership from accounts that do not require kprobe access.

Patch Information

The fix has been merged and backported across stable branches. Reference commits include Kernel Git Commit 92750bf, Kernel Git Commit 01f91d4, Kernel Git Commit 21da6d3, Kernel Git Commit 22f935b, Kernel Git Commit 39dfc97, Kernel Git Commit 422e565, Kernel Git Commit 64773b3, and Kernel Git Commit 67abac2. Distributions including Debian have shipped corresponding updates.

Workarounds

Disable dynamic kprobe tracing where not required by setting /proc/sys/kernel/kprobes-optimization and locking down /sys/kernel/tracing permissions to root-only.
Set kernel.perf_event_paranoid=3 to block unprivileged use of perf_event_open for tracepoint and kprobe events.
Restrict tracefs mounts via mount options mode=0700 and gid=0 until patched kernels are deployed across the arm64 fleet.

bash

# Configuration example
# Tighten tracing and perf access until patched kernels are deployed
sysctl -w kernel.perf_event_paranoid=3
sysctl -w kernel.kptr_restrict=2
sysctl -w kernel.dmesg_restrict=1

# Remove world/group access to tracefs
mount -o remount,mode=0700,gid=0 /sys/kernel/tracing

# Verify the running kernel includes the fix
dmesg | grep -i "regs_get_kernel_stack_nth" || echo "No KASAN reports observed"
uname -r