CVE-2025-71102: Linux Kernel Privilege Escalation Flaw

CVE-2025-71102 Overview

A parameter type mismatch vulnerability has been identified in the Linux kernel's Shadow Call Stack (SCS) implementation. The __scs_magic() function requires a void * parameter, but a struct task_struct * is incorrectly passed. This bug affects the scs_check_usage debugging function, which is used to monitor shadow call stack usage when CONFIG_DEBUG_STACK_USAGE is enabled.

The shadow call stack is a security feature designed to protect return addresses from being overwritten during control-flow attacks. The task_scs(tsk) function returns the starting address of a task's shadow call stack, and __scs_magic(task_scs(tsk)) should provide the end address. The incorrect parameter causes the function to scan an incorrect memory range.

Critical Impact
When CONFIG_DEBUG_STACK_USAGE is enabled, this bug causes inaccurate stack usage reporting and could potentially trigger a kernel panic if unmapped memory is accessed during the for loop scan.

Affected Products

Linux Kernel (versions with Shadow Call Stack and CONFIG_DEBUG_STACK_USAGE enabled)
ARM64-based systems using SCS security features
Development and testing environments with debug configurations

Discovery Timeline

2026-01-14 - CVE CVE-2025-71102 published to NVD
2026-01-19 - Last updated in NVD database

Technical Details for CVE-2025-71102

Vulnerability Analysis

The vulnerability exists within the Shadow Call Stack (SCS) subsystem of the Linux kernel, specifically in the __scs_magic() function. The SCS is a compiler-based security mechanism that maintains a separate stack for storing return addresses, protecting against return-oriented programming (ROP) attacks.

The root issue is a type confusion where the function expects a void * pointer to calculate the magic value at the end of the shadow call stack, but receives a struct task_struct * instead. This causes the scs_check_usage function to scan an incorrect memory region when calculating stack usage statistics.

The practical impact manifests in two ways: First, stack usage statistics reported in kernel messages (kmsg) will be inaccurate because the function scans the wrong memory range. Second, if the value returned by __scs_magic(tsk) exceeds that of __scs_magic(task_scs(tsk)), the for loop may attempt to access unmapped memory regions, potentially causing a kernel panic.

However, this scenario is mitigated by the kernel's memory allocation patterns—task_struct is allocated via the slab allocator (typically returning lower addresses), while the shadow call stack is allocated via vmalloc() (typically returning higher addresses). Since this affects only the debugging feature enabled by CONFIG_DEBUG_STACK_USAGE, production systems running default configurations are unaffected.

Root Cause

The root cause is an incorrect parameter being passed to the __scs_magic() function. The function is designed to receive a void * pointer representing the shadow call stack address via task_scs(tsk), but instead receives the raw struct task_struct * pointer (tsk). The correct invocation should be __scs_magic(task_scs(tsk)) to properly calculate the end address of the task's shadow call stack.

Attack Vector

This is primarily a debugging-related bug rather than a security vulnerability with a clear external attack vector. The issue only manifests when:

The kernel is compiled with CONFIG_DEBUG_STACK_USAGE enabled
The system uses Shadow Call Stack security features (ARM64)
The scs_check_usage function is invoked to check stack usage

The vulnerability cannot be directly exploited by remote attackers and requires local access to a system running a debug-configured kernel. The primary risk is denial of service through kernel panic if the incorrect memory access occurs during stack usage scanning.

Detection Methods for CVE-2025-71102

Indicators of Compromise

Kernel panic messages referencing SCS or shadow call stack subsystem
Unexpected or obviously incorrect shadow call stack usage values in kernel logs
System crashes during debugging operations on ARM64 systems with SCS enabled

Detection Strategies

Review kernel logs (dmesg/kmsg) for anomalous shadow call stack usage statistics
Monitor for kernel oops or panics originating from the scs_check_usage function
Check kernel configuration for CONFIG_DEBUG_STACK_USAGE=y and CONFIG_SHADOW_CALL_STACK=y

Monitoring Recommendations

Implement kernel log monitoring for SCS-related errors on affected systems
Track system stability metrics on development/testing environments using debug kernel configurations
Set up alerts for unexpected kernel panics on ARM64 systems with shadow call stack enabled

How to Mitigate CVE-2025-71102

Immediate Actions Required

Apply the kernel patches from the official kernel git repository
Disable CONFIG_DEBUG_STACK_USAGE in production environments if patching is not immediately possible
Review and update kernel configurations on development and testing systems

Patch Information

The Linux kernel maintainers have released patches to correct the parameter type in the __scs_magic() function call. Multiple patch commits are available for different kernel branches:

Workarounds

Disable CONFIG_DEBUG_STACK_USAGE in kernel configuration if the debugging feature is not actively needed
Ensure production systems use standard kernel configurations without debug options enabled
For development environments, apply the patch or upgrade to a fixed kernel version before enabling debug features

bash

# Check current kernel configuration for affected options
zcat /proc/config.gz | grep -E "(DEBUG_STACK_USAGE|SHADOW_CALL_STACK)"

# If CONFIG_DEBUG_STACK_USAGE=y, consider recompiling kernel with it disabled
# In kernel configuration:
# CONFIG_DEBUG_STACK_USAGE is not set