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 1CFE823ED5B; Fri, 9 Jan 2026 12:10:15 +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=1767960616; cv=none; b=e5zOQaVSy3qZHrLtmED4I06xfk2GvD4jq6N93xfC55AKwyuKYEq5BeQtM8asquU6bVrREApYu+19LvFhf6QY320C7xJaeN3PSz9Cb+v4TlzmmF/l6F1+DJFFfuOqtCfZ8Rc7hM4x4ZwU3SF3NKK4GIcFX5TMP5c54wHdAD2t+ZI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767960616; c=relaxed/simple; bh=9nzShEq1csnzae3gy/fHbRqG5JjkhwJ/+HzBhxuhWUU=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=PsqHpC3XOFl/wDAFp1/6vYg+568aJ0SZtb7ySP3hAEvTh+pughRogKJm7TVPgInvLQm/vY2bPP0nbEP1MZqUWMVHz9pU8mD8T7SQI8JE7ED6wmN8+5vZM2KW7Oi4bHkKz3tmgOdyaP7eb76N36yYaNT6LTjuoV8mmuMJ7+WfQT0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=AoXU0hBC; 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="AoXU0hBC" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3699BC19423; Fri, 9 Jan 2026 12:10:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1767960615; bh=9nzShEq1csnzae3gy/fHbRqG5JjkhwJ/+HzBhxuhWUU=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=AoXU0hBCoXBMP7xOAEs5Y+Tt3dQIKZY2Z2iYDRytRv0zDIRY7rcwaYeA5qEXplm0g r2EhM7AZi+O3wm3rIu/sUnT7bDlRIgdHOBVx/vdLs2ROmJiIdT37ydSVBl/uhjrrGS ZN7vWs8OraSBF/C5Mj+Fan4/4Cr75PJF9tobke68= 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.6 459/737] scs: fix a wrong parameter in __scs_magic Date: Fri, 9 Jan 2026 12:39:58 +0100 Message-ID: <20260109112151.258145909@linuxfoundation.org> X-Mailer: git-send-email 2.52.0 In-Reply-To: <20260109112133.973195406@linuxfoundation.org> References: <20260109112133.973195406@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.6-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 @@ -135,7 +135,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);