CVE-2025-38320
NoneCVSS
—
EPSS
0.2%
Published
Jul 10, 2025
CISA due date
—
Cloudanix analysis
A flaw in the Linux kernel's process tracing code could let attackers peek at protected memory areas, potentially destabilizing systems or aiding further attacks until kernels are updated.
- Exploitation
- Local Privilege
- Attacker needs
- Low Privilege
- Complexity
- Theoretical
- Impact
- Other
- Component
- OS kernel
- Class
- Buffer Overflow
- Remediation
- Patch
- Effort
- Medium
- Patch risk
- Low
What it actually does
The flaw allows a stack-out-of-bounds read in regs_get_kernel_stack_nth() on arm64 when KASAN instrumentation validates an address already confirmed to be on the task stack, triggering false-positive reports during kprobe and ptrace operations.
Why it matters to the business
Kernel panics or noisy security alerts can interrupt system stability and monitoring on affected Linux distributions, increasing operational overhead especially in environments with many downstream kernel dependents and active exploitation campaigns targeting similar kernel flaws.
How an attack unfolds
An attacker with local access triggers kprobe or ptrace paths that invoke regs_get_kernel_stack_nth(), causing the out-of-bounds read; threat actors in Advanced Spyware Campaign and Linux Kernel Privilege Escalation efforts (CVE-2025-38350, CVE-2025-38477, CVE-2025-38083) may chain this with other kernel bugs for memory disclosure or escalation.
How to fix it
Upgrade linux-lts packages to the fixed versions: 6.1.81-r0 for Alpaquita 23, 6.6.58-r0 or 6.12.41-r0 for Alpaquita stream, and apply commit 64773b3ea09235168a549a195cba43bb867c4a17 in the stable GIT tree; rebuild and reboot all affected kernels.
How to confirm the fix worked
Confirm the patch is present by checking for READ_ONCE_NOCHECK() usage in regs_get_kernel_stack_nth(), verify no KASAN reports occur under the same kprobe/ptrace workload, and ensure kernel version matches or exceeds the listed fixed releases.
Typical attack path
- Obtain local code execution on an affected arm64 Linux system
- Attach a kprobe or invoke ptrace operations that call process_fetch_insn
- Reach regs_get_kernel_stack_nth() with a stack address near frame boundary
- Trigger KASAN-detected read of size 8 outside the validated stack object
- Observe kernel oops or use the read for further information disclosure
How to detect it
Search kernel logs for KASAN stack-out-of-bounds reports mentioning regs_get_kernel_stack_nth and process_fetch_insn; correlate with unusual ptrace or kprobe activity from processes owned by untrusted users; review audit logs for recent kernel_clone and sys_clone calls near the crash time.
What your security team should do
- Immediately schedule kernel upgrades on all arm64 systems to the exact fixed versions provided
- Prioritize patching in high-prevalence environments and those already targeted by September 2025 Active Exploitation Campaigns
- Enable KASAN in test kernels to validate the fix before production rollout
- Monitor EPSS trend and threat actor activity for similar Linux kernel issues
- Review ptrace and kprobe usage policies to reduce attack surface until patches are applied
The record
In the Linux kernel, the following vulnerability has been resolved: arm64/ptrace: Fix stack-out-of-bounds read in regs_get_kernel_stack_nth() KASAN reports a stack-out-of-bounds read in regs_get_kernel_stack_nth(). Call Trace: [ 97.283505] BUG: KASAN: stack-out-of-bounds in regs_get_kernel_stack_nth+0xa8/0xc8 [ 97.284677] Read of size 8 at addr ffff800089277c10 by task 1.sh/2550 [ 97.285732] [ 97.286067] CPU: 7 PID: 2550 Comm: 1.sh Not tainted 6.6.0+ #11 [ 97.287032] Hardware name: linux,dummy-virt (DT) [ 97.287815] Call trace: [ 97.288279] dump_backtrace+0xa0/0x128 [ 97.288946] show_stack+0x20/0x38 [ 97.289551] dump_stack_lvl+0x78/0xc8 [ 97.290203] print_address_description.constprop.0+0x84/0x3c8 [ 97.291159] print_report+0xb0/0x280 [ 97.291792] kasan_report+0x84/0xd0 [ 97.292421] __asan_load8+0x9c/0xc0 [ 97.293042] regs_get_kernel_stack_nth+0xa8/0xc8 [ 97.293835] process_fetch_insn+0x770/0xa30 [ 97.294562] kprobe_trace_func+0x254/0x3b0 [ 97.295271] kprobe_dispatcher+0x98/0xe0 [ 97.295955] kprobe_breakpoint_handler+0x1b0/0x210 [ 97.296774] call_break_hook+0xc4/0x100 [ 97.297451] brk_handler+0x24/0x78 [ 97.298073] do_debug_exception+0xac/0x178 [ 97.298785] el1_dbg+0x70/0x90 [ 97.299344] el1h_64_sync_handler+0xcc/0xe8 [ 97.300066] el1h_64_sync+0x78/0x80 [ 97.300699] kernel_clone+0x0/0x500 [ 97.301331] __arm64_sys_clone+0x70/0x90 [ 97.302084] invoke_syscall+0x68/0x198 [ 97.302746] el0_svc_common.constprop.0+0x11c/0x150 [ 97.303569] do_el0_svc+0x38/0x50 [ 97.304164] el0_svc+0x44/0x1d8 [ 97.304749] el0t_64_sync_handler+0x100/0x130 [ 97.305500] el0t_64_sync+0x188/0x190 [ 97.306151] [ 97.306475] The buggy address belongs to stack of task 1.sh/2550 [ 97.307461] and is located at offset 0 in frame: [ 97.308257] __se_sys_clone+0x0/0x138 [ 97.308910] [ 97.309241] This frame has 1 object: [ 97.309873] [48, 184) 'args' [ 97.309876] [ 97.310749] The buggy address belongs to the virtual mapping at [ 97.310749] [ffff800089270000, ffff800089279000) created by: [ 97.310749] dup_task_struct+0xc0/0x2e8 [ 97.313347] [ 97.313674] The buggy address belongs to the physical page: [ 97.314604] page: refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x14f69a [ 97.315885] flags: 0x15ffffe00000000(node=1|zone=2|lastcpupid=0xfffff) [ 97.316957] raw: 015ffffe00000000 0000000000000000 dead000000000122 0000000000000000 [ 97.318207] raw: 0000000000000000 0000000000000000 00000001ffffffff 0000000000000000 [ 97.319445] page dumped because: kasan: bad access detected [ 97.320371] [ 97.320694] Memory state around the buggy address: [ 97.321511] ffff800089277b00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 97.322681] ffff800089277b80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 97.323846] >ffff800089277c00: 00 00 f1 f1 f1 f1 f1 f1 00 00 00 00 00 00 00 00 [ 97.325023] ^ [ 97.325683] ffff800089277c80: 00 00 00 00 00 00 00 00 00 f3 f3 f3 f3 f3 f3 f3 [ 97.326856] ffff800089277d00: f3 f3 00 00 00 00 00 00 00 00 00 00 00 00 00 00 This issue seems to be related to the behavior of some gcc compilers and was also fixed on the s390 architecture before: commit d93a855c31b7 ("s390/ptrace: Avoid KASAN false positives in regs_get_kernel_stack_nth()") As described in that commit, regs_get_kernel_stack_nth() has confirmed that `addr` is on the stack, so reading the value at `*addr` should be allowed. Use READ_ONCE_NOCHECK() helper to silence the KASAN check for this case. [will: Use '*addr' as the argument to READ_ONCE_NOCHECK()]
Affected packages
| Ecosystem | Package | Introduced | Fixed |
|---|---|---|---|
| Debian:11 | linux | 0 | No fix |
| Debian:12 | linux | 0 | No fix |
| Debian:13 | linux | 0 | 6.12.35-1 |
| Debian:14 | linux | 0 | 6.12.35-1 |
| Linux | Kernel | 4.8.0 | 5.4.295 |
| Mageia:9 | kernel | 0 | 6.6.101-1.mga9 |
| Mageia:9 | kernel-linus | 0 | 6.6.101-1.mga9 |
| Mageia:9 | kmod-virtualbox | 0 | 7.1.10-7.mga9 |
| Mageia:9 | kmod-xtables-addons | 0 | 3.24-83.mga9 |
| Mageia:9 | wireless-regdb | 0 | 20250710-1.mga9 |
Related vulnerabilities
- CVE-2025-39885 In the Linux kernel, the following vulnerability has been resolved: ocfs2: fix recursive… Also affects linux
- CVE-2025-39883 In the Linux kernel, the following vulnerability has been resolved: mm/memory-failure… Also affects linux
- CVE-2025-39876 In the Linux kernel, the following vulnerability has been resolved: net: fec: Fix… Also affects linux
- CVE-2025-39869 In the Linux kernel, the following vulnerability has been resolved: dmaengine: ti: edma… Also affects linux
- CVE-2025-39873 In the Linux kernel, the following vulnerability has been resolved: can: xilinx_can… Also affects linux
- CVE-2025-39863 In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: fix… Also affects linux
- CVE-2025-39865 In the Linux kernel, the following vulnerability has been resolved: tee: fix NULL pointer… Also affects linux
- CVE-2025-39866 In the Linux kernel, the following vulnerability has been resolved: fs: writeback: fix… Also affects linux