From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 15DF235CB6A; Fri, 9 Jan 2026 12:40:11 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767962411; cv=none; b=QA5ShYUYaXwMk2odQlIB82g57ttk1BBiGJ4CUdYdEfdM2SaQmx8IKE2uGiBY33y0+ZR5P5rrRKa8x31HoLMWYs3YUfhpQndbB+h6Uo3dPZgnw/GZQPoMijB7LCiAgWFD5xCZZyEDOabs5W2CITpGLO0x/uL6yH+/W2eqtucSdmQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767962411; c=relaxed/simple; bh=BTVXlOKYxI3PVxRl5suoE73R9JS1yNXhsrQ3JMZOwyY=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=FwCqyBgQuQN5YpmATswPjXBxAAY2ocCbkjFMFWuTRpOIllH4Na+gP0SuGy8v+Ae2AMa+K11JqYzoY64dQbSu7Pkxkmhyu3LOEMMBjmAnbA4kX9GMimPkCzCPtnltD867lVadMcm2HKdwJdE0mH+Fwk2ltgOUvKAVxlXnofZU3Zg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=alA1IqOM; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="alA1IqOM" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 96E6CC4CEF1; Fri, 9 Jan 2026 12:40:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1767962411; bh=BTVXlOKYxI3PVxRl5suoE73R9JS1yNXhsrQ3JMZOwyY=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=alA1IqOM1Rb2jRniHlEI5I+7je75qqtjuPuenPw7y8cAJy/W9O/n1avNxAw+1VtKE P4RKYdX5hcIfmvB2uvE+ccpG2vVMFvZDE96f5l42Q1kcjxdUG+uaSKXT1CJ500/Nyg vWDdW445+W4bqkCfWGBSNM2CMjkCi1iz4vwTceDw= From: Greg Kroah-Hartman To: stable@vger.kernel.org Cc: Greg Kroah-Hartman , patches@lists.linux.dev, Jiyuan Xie , Zhichi Lin , Sami Tolvanen , Will Deacon , Andrey Konovalov , Kees Cook , Marco Elver , Yee Lee , Andrew Morton Subject: [PATCH 6.1 356/634] scs: fix a wrong parameter in __scs_magic Date: Fri, 9 Jan 2026 12:40:34 +0100 Message-ID: <20260109112130.920007481@linuxfoundation.org> X-Mailer: git-send-email 2.52.0 In-Reply-To: <20260109112117.407257400@linuxfoundation.org> References: <20260109112117.407257400@linuxfoundation.org> User-Agent: quilt/0.69 X-stable: review X-Patchwork-Hint: ignore Precedence: bulk X-Mailing-List: stable@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit 6.1-stable review patch. If anyone has any objections, please let me know. ------------------ From: Zhichi Lin commit 08bd4c46d5e63b78e77f2605283874bbe868ab19 upstream. __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 to: 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. Link: https://lkml.kernel.org/r/20251011082222.12965-1-zhichi.lin@vivo.com Fixes: 5bbaf9d1fcb9 ("scs: Add support for stack usage debugging") Signed-off-by: Jiyuan Xie Signed-off-by: Zhichi Lin Reviewed-by: Sami Tolvanen Acked-by: Will Deacon Cc: Andrey Konovalov Cc: Kees Cook Cc: Marco Elver Cc: Will Deacon Cc: Yee Lee Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman --- kernel/scs.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/kernel/scs.c +++ b/kernel/scs.c @@ -125,7 +125,7 @@ static void scs_check_usage(struct task_ if (!IS_ENABLED(CONFIG_DEBUG_STACK_USAGE)) return; - for (p = task_scs(tsk); p < __scs_magic(tsk); ++p) { + for (p = task_scs(tsk); p < __scs_magic(task_scs(tsk)); ++p) { if (!READ_ONCE_NOCHECK(*p)) break; used += sizeof(*p);