linux-kernel - [PATCH v3] riscv: fix using wrong load type

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <20250819071318.21103-1-jimmy.ho@sifive.com>
Date: Tue, 19 Aug 2025 15:13:18 +0800
From: Jimmy Ho <jimmy.ho@...ive.com>
To: linux-riscv@...ts.infradead.org
Cc: troy.mitchell@...ux.spacemit.com,
	ziyao@...root.org,
	paul.walmsley@...ive.com,
	palmer@...belt.com,
	aou@...s.berkeley.edu,
	alex@...ti.fr,
	cyrilbur@...storrent.com,
	cleger@...osinc.com,
	charlie@...osinc.com,
	kees@...nel.org,
	ben.dooks@...ethink.co.uk,
	jszhang@...nel.org,
	linux-kernel@...r.kernel.org,
	Jimmy Ho <jimmy.ho@...ive.com>
Subject: [PATCH v3] riscv: fix using wrong load type

thread_info.cpu field is 32 bits wide,
but is accessed using an XLEN-bit load, which might be 64bit load, fix it

Changes in v3:
- replace space with tab to keep it aligned with code block
- Add "Fixes" tag

Changes in v2:
- add a comment to explain why use lw instead of REG_L.
- correct commit message

Fixes: 503638e0babf3 ("riscv: Stop emitting preventive sfence.vma for new vmalloc mappings")
Signed-off-by: Jimmy Ho <jimmy.ho@...ive.com>
---
 arch/riscv/kernel/entry.S | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/riscv/kernel/entry.S b/arch/riscv/kernel/entry.S
index 3a0ec6fd5956..492ae936dccd 100644
--- a/arch/riscv/kernel/entry.S
+++ b/arch/riscv/kernel/entry.S
@@ -45,8 +45,10 @@
 	 * Computes:
 	 * a0 = &new_vmalloc[BIT_WORD(cpu)]
 	 * a1 = BIT_MASK(cpu)
+	 * 
+	 * using lw instead of REG_L is because the thread_info.cpu field is 32 bits wide
 	 */
-	REG_L 	a2, TASK_TI_CPU(tp)
+	lw	a2, TASK_TI_CPU(tp)
 	/*
 	 * Compute the new_vmalloc element position:
 	 * (cpu / 64) * 8 = (cpu >> 6) << 3
-- 
2.39.3