CVE-2025-71102

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