cbcvebase.
CVE-2025-71102
published 2026-01-14

CVE-2025-71102: In the Linux kernel, the following vulnerability has been resolved: scs: fix a wrong parameter in __scs_magic __scs_magic() needs a 'void *' variable, but a…

PriorityP422medium5.5CVSS 3.1
AVLACLPRLUINSUCNINAH
EPSS
0.12%
2.4th percentile
In the Linux kernel, the following vulnerability has been resolved: scs: fix a wrong parameter in __scs_magic __scs_magic() needs a 'void *' variable, but a 'struct task_struct *' is given. 'task_scs(tsk)' is the starting address of the task's shadow call stack, and '__scs_magic(task_scs(tsk))' is the end address of the task's shadow call stack. Here should be '__scs_magic(task_scs(tsk))'. The user-visible effect of this bug is that when CONFIG_DEBUG_STACK_USAGE is enabled, the shadow call stack usage checking function (scs_check_usage) would scan an incorrect memory range. This could lead 1. **Inaccurate stack usage reporting**: The function would calculate wrong usage statistics for the shadow call stack, potentially showing incorrect value in kmsg. 2. **Potential kernel crash**: If the value of __scs_magic(tsk)is greater than that of __scs_magic(task_scs(tsk)), the for loop may access unmapped memory, potentially causing a kernel panic. However, this scenario is unlikely because task_struct is allocated via the slab allocator (which typically returns lower addresses), while the shadow call stack returned by task_scs(tsk) is allocated via vmalloc(which typically returns higher addresses). However, since this is purely a debugging feature (CONFIG_DEBUG_STACK_USAGE), normal production systems should be not unaffected. The bug only impacts developers and testers who are actively debugging stack usage with this configuration enabled.

Affected

59 ranges· showing 25
VendorProductVersion rangeFixed in
debianlinux< linux 6.1.162-1 (bookworm)linux 6.1.162-1 (bookworm)
debianlinux-6.1< linux 6.1.162-1 (bookworm)linux 6.1.162-1 (bookworm)
linuxlinux
linuxlinux>= 5bbaf9d1fcb9be696ee9a61636ab6803556c70f2 < 1727e8bd69103a68963a5613a0ddb6d8d37df5d31727e8bd69103a68963a5613a0ddb6d8d37df5d3
linuxlinux>= 5bbaf9d1fcb9be696ee9a61636ab6803556c70f2 < cfdf6250b63b953b1d8e60814c8ca96c6f9d1c8ccfdf6250b63b953b1d8e60814c8ca96c6f9d1c8c
linuxlinux>= 5bbaf9d1fcb9be696ee9a61636ab6803556c70f2 < 57ba40b001be27786d0570dd292289df748b306b57ba40b001be27786d0570dd292289df748b306b
linuxlinux>= 5bbaf9d1fcb9be696ee9a61636ab6803556c70f2 < 062774439d442882b44f5eab8c256ad3423ef284062774439d442882b44f5eab8c256ad3423ef284
linuxlinux>= 5bbaf9d1fcb9be696ee9a61636ab6803556c70f2 < 9ef28943471a16e4f9646bc3e8e2de148e7d8d7b9ef28943471a16e4f9646bc3e8e2de148e7d8d7b
linuxlinux>= 5bbaf9d1fcb9be696ee9a61636ab6803556c70f2 < a19fb3611e4c06624fc0f83ef19f4fb8d57d4751a19fb3611e4c06624fc0f83ef19f4fb8d57d4751
linuxlinux>= 5bbaf9d1fcb9be696ee9a61636ab6803556c70f2 < 08bd4c46d5e63b78e77f2605283874bbe868ab1908bd4c46d5e63b78e77f2605283874bbe868ab19
linuxlinux_kernel
linuxlinux_kernel
linuxlinux_kernel>= 0 < 5.10.249-15.10.249-1
linuxlinux_kernel>= 0 < 6.1.162-16.1.162-1
linuxlinux_kernel>= 0 < 6.12.69-16.12.69-1
linuxlinux_kernel>= 0 < 6.18.3-16.18.3-1
linuxlinux_kernel>= 0 < 5.15.0-173.1835.15.0-173.183
linuxlinux_kernel>= 5.11 < 5.15.1985.15.198
linuxlinux_kernel>= 5.11.0 < 5.15.1985.15.198
linuxlinux_kernel>= 5.16 < 6.1.1606.1.160
linuxlinux_kernel>= 5.16.0 < 6.1.1606.1.160
linuxlinux_kernel>= 5.8.0 < 5.10.2485.10.248
linuxlinux_kernel>= 5.8.1 < 5.10.2485.10.248
linuxlinux_kernel>= 6.13 < 6.18.36.18.3
linuxlinux_kernel>= 6.13.0 < 6.18.36.18.3

CVSS provenance

nvdv3.15.5MEDIUMCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
osv7.8HIGH
vendor_ubuntu7.8HIGH
vendor_debian5.5MEDIUM
vendor_redhat5.5MEDIUM
Stop checking back — get the weekly exploitation signal.

Every Monday: what got weaponized or added to CISA KEV in the last seven days — each CVE cross-linked to its PoC, Nuclei template, and detection rule. Free, one email a week, unsubscribe in one click.