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 C8D361DF269; Mon, 4 Aug 2025 00:37:28 +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=1754267848; cv=none; b=HDHpRBIKN+1+hqhZb6sgUoE2IOdU2xUCvxmah9J2umHSSKGGenxq659BP9WTn0fMPJa4b1QCc5jnxiPFSYpTgI2WauEAFCBsvIdrBqCNjdD4RutqBvoKU0cztFk0rqV/HuNt05j3Lpq/44TETkqZfo7mT60igsOr5VyNdlfNB10= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1754267848; c=relaxed/simple; bh=F90JFq2DA2hyVOvaTR4oDxz+L1hPDd0NDSpOfIUY/Ww=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=FRMtc02XYMA6QcldipMioJPTK60rKwiDx/MedD+s1aR4/vcLaXEzGlVHeNjEmnqJFrtI7/Oeo/srmWxQKsuuKmEdLbe7jreUqSrI7gxeKlVGxdkFeApYGJEgzbcRlsxOMRN40l/B8B+IkzKWe7evgWDJLtzfPpZzB/ZURWA0SGc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Y7K8+Wdn; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Y7K8+Wdn" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3A5EBC4CEEB; Mon, 4 Aug 2025 00:37:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1754267848; bh=F90JFq2DA2hyVOvaTR4oDxz+L1hPDd0NDSpOfIUY/Ww=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Y7K8+Wdn8ZKtiNJ9dSvsdYGkFUMNkkiAGwpbVv/gm3GlkPC+HcmUgOkn+4STPFuXl 7wnzqTfWJpShE7WT2TRxFJvZNCoGNZOsBa822mTkIO7vU9Cmrei1gSqbI4GKN1y/dr TLfYGneRXsFiFaPhbqxqtmmRaHxGAR4CTim5B6ZEcYZVuOtREj/+cFO9XAIsGANo/T 4cXi4SPjTwNJbgNQBzR14AfZooEetrJwzV98kwIYU6qjn174M0B0wdecLomqMIyBvZ 6l8qxnFg5d9G++bqfpUBdigTKLRbGPAsWYGnJjRUmMR70EjX32hkD9GiCl8a3ZBgOd y8mM9FeBACtCg== From: Sasha Levin To: patches@lists.linux.dev, stable@vger.kernel.org Cc: Aaron Kling , Thierry Reding , Sasha Levin , thierry.reding@gmail.com, jonathanh@nvidia.com, linux-arm-kernel@lists.infradead.org, linux-tegra@vger.kernel.org Subject: [PATCH AUTOSEL 6.1 20/51] ARM: tegra: Use I/O memcpy to write to IRAM Date: Sun, 3 Aug 2025 20:36:12 -0400 Message-Id: <20250804003643.3625204-20-sashal@kernel.org> X-Mailer: git-send-email 2.39.5 In-Reply-To: <20250804003643.3625204-1-sashal@kernel.org> References: <20250804003643.3625204-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: stable@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore X-stable-base: Linux 6.1.147 Content-Transfer-Encoding: 8bit From: Aaron Kling [ Upstream commit 398e67e0f5ae04b29bcc9cbf342e339fe9d3f6f1 ] Kasan crashes the kernel trying to check boundaries when using the normal memcpy. Signed-off-by: Aaron Kling Link: https://lore.kernel.org/r/20250522-mach-tegra-kasan-v1-1-419041b8addb@gmail.com Signed-off-by: Thierry Reding Signed-off-by: Sasha Levin --- LLM Generated explanations, may be completely bogus: Based on my analysis of this commit, here's my determination: **Backport Status: YES** This commit should be backported to stable kernel trees for the following reasons: 1. **Fixes a real crash/bug**: The commit fixes a KASAN (Kernel Address Sanitizer) crash that occurs when using regular `memcpy()` to write to IRAM (Internal RAM). This is a functional bug that causes kernel crashes when KASAN is enabled. 2. **Small and contained fix**: The change is minimal - it simply replaces `memcpy()` with `memcpy_toio()` on line 66 of arch/arm/mach- tegra/reset.c. This is a one-line change that doesn't alter any logic or introduce new features. 3. **Follows proper I/O memory access patterns**: The fix is technically correct. According to the kernel documentation in Documentation/driver-api/device-io.rst, I/O memory regions (which IRAM is mapped as via `IO_ADDRESS()`) should be accessed using I/O-specific functions like `memcpy_toio()` rather than regular `memcpy()`. The documentation explicitly states: "Do not use memset or memcpy on IO addresses; they are not guaranteed to copy data in order." 4. **No architectural changes**: The commit doesn't introduce any architectural changes or new functionality. It's purely a bug fix that corrects improper memory access. 5. **Minimal risk of regression**: Since this change only affects how data is copied to IRAM during the Tegra CPU reset handler initialization, and uses the proper kernel API for I/O memory access, the risk of introducing new issues is very low. 6. **Platform-specific but important**: While this fix is specific to ARM Tegra platforms, it fixes a crash that would affect any Tegra system running with KASAN enabled. This is important for developers and users who rely on KASAN for debugging. The fact that `iram_base` is obtained through `IO_ADDRESS()` macro clearly indicates this is I/O mapped memory that requires I/O-specific accessors. KASAN correctly identified this misuse and crashed to prevent potential issues. The fix properly uses `memcpy_toio()` which is designed for copying to I/O memory regions and won't trigger KASAN checks for regular memory access. arch/arm/mach-tegra/reset.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/mach-tegra/reset.c b/arch/arm/mach-tegra/reset.c index d5c805adf7a8..ea706fac6358 100644 --- a/arch/arm/mach-tegra/reset.c +++ b/arch/arm/mach-tegra/reset.c @@ -63,7 +63,7 @@ static void __init tegra_cpu_reset_handler_enable(void) BUG_ON(is_enabled); BUG_ON(tegra_cpu_reset_handler_size > TEGRA_IRAM_RESET_HANDLER_SIZE); - memcpy(iram_base, (void *)__tegra_cpu_reset_handler_start, + memcpy_toio(iram_base, (void *)__tegra_cpu_reset_handler_start, tegra_cpu_reset_handler_size); err = call_firmware_op(set_cpu_boot_addr, 0, reset_address); -- 2.39.5