The LoongArch syscall number is directly controlled by userspace, but
does not have a array_index_nospec() boundry to prevent access past the
syscall function pointer tables.

Cc: Huacai Chen <chenhuacai@kernel.org>
Cc: WANG Xuerui <kernel@xen0n.name>
Assisted-by: gkh_clanker_2000
Cc: stable <stable@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
My scripts caught this as I think LoongArch is vulnerable to the
old-style Spectre 1 issues, but I couldn't find where it was addressed
in the syscall path.  Did I just miss it somewhere, or is this patch
still needed?

 arch/loongarch/kernel/syscall.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/loongarch/kernel/syscall.c b/arch/loongarch/kernel/syscall.c
index 1249d82c1cd0..f2c98bbafce3 100644
--- a/arch/loongarch/kernel/syscall.c
+++ b/arch/loongarch/kernel/syscall.c
@@ -8,6 +8,7 @@
 #include <linux/capability.h>
 #include <linux/entry-common.h>
 #include <linux/errno.h>
+#include <linux/nospec.h>
 #include <linux/linkage.h>
 #include <linux/objtool.h>
 #include <linux/randomize_kstack.h>
@@ -74,6 +75,7 @@ void noinstr __no_stack_protector do_syscall(struct pt_regs *regs)
 	add_random_kstack_offset();
 
 	if (nr < NR_syscalls) {
+		nr = array_index_nospec(nr, NR_syscalls);
 		syscall_fn = sys_call_table[nr];
 		regs->regs[4] = syscall_fn(regs->orig_a0, regs->regs[5], regs->regs[6],
 					   regs->regs[7], regs->regs[8], regs->regs[9]);
-- 
2.53.0

On Tue, 2026-03-24 at 17:30 +0100, Greg Kroah-Hartman wrote:
> The LoongArch syscall number is directly controlled by userspace, but
> does not have a array_index_nospec() boundry to prevent access past
> the
> syscall function pointer tables.
> 
> Cc: Huacai Chen <chenhuacai@kernel.org>
> Cc: WANG Xuerui <kernel@xen0n.name>
> Assisted-by: gkh_clanker_2000
> Cc: stable <stable@kernel.org>
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> ---
> My scripts caught this as I think LoongArch is vulnerable to the

There's no evidence.  The kernel currently report all LoongArch
processors invulnerable to spectre V1 via cpuinfo.

So NAK unless there's a reproducer of spectre V1 on LoongArch.  If so
we'd also need to adjust the cpuinfo output.

-- 
Xi Ruoyao <xry111@xry111.site>

On Wed, Mar 25, 2026 at 11:26:29AM +0800, Xi Ruoyao wrote:
> On Tue, 2026-03-24 at 17:30 +0100, Greg Kroah-Hartman wrote:
> > The LoongArch syscall number is directly controlled by userspace, but
> > does not have a array_index_nospec() boundry to prevent access past
> > the
> > syscall function pointer tables.
> > 
> > Cc: Huacai Chen <chenhuacai@kernel.org>
> > Cc: WANG Xuerui <kernel@xen0n.name>
> > Assisted-by: gkh_clanker_2000
> > Cc: stable <stable@kernel.org>
> > Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > ---
> > My scripts caught this as I think LoongArch is vulnerable to the
> 
> There's no evidence.  The kernel currently report all LoongArch
> processors invulnerable to spectre V1 via cpuinfo.

Where is that?  In the sysfs files, or in the actual silicon testing?

> So NAK unless there's a reproducer of spectre V1 on LoongArch.  If so
> we'd also need to adjust the cpuinfo output.

I really thought this cpu was vulnerable to this, but if the companies
say it isn't, then great, but reports like this:
	https://cc-sw.com/chinese-loongarch-architecture-evaluation-part-3-of-3/
say that the silicon is vulnerable.  So, which is it?

confused,

greg k-h

On Wed, Mar 25, 2026 at 09:53:09AM +0100, Greg Kroah-Hartman wrote:
> On Wed, Mar 25, 2026 at 11:26:29AM +0800, Xi Ruoyao wrote:
> > On Tue, 2026-03-24 at 17:30 +0100, Greg Kroah-Hartman wrote:
> > > The LoongArch syscall number is directly controlled by userspace, but
> > > does not have a array_index_nospec() boundry to prevent access past
> > > the
> > > syscall function pointer tables.
> > > 
> > > Cc: Huacai Chen <chenhuacai@kernel.org>
> > > Cc: WANG Xuerui <kernel@xen0n.name>
> > > Assisted-by: gkh_clanker_2000
> > > Cc: stable <stable@kernel.org>
> > > Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > > ---
> > > My scripts caught this as I think LoongArch is vulnerable to the
> > 
> > There's no evidence.  The kernel currently report all LoongArch
> > processors invulnerable to spectre V1 via cpuinfo.
> 
> Where is that?  In the sysfs files, or in the actual silicon testing?
> 
> > So NAK unless there's a reproducer of spectre V1 on LoongArch.  If so
> > we'd also need to adjust the cpuinfo output.
> 
> I really thought this cpu was vulnerable to this, but if the companies
> say it isn't, then great, but reports like this:
> 	https://cc-sw.com/chinese-loongarch-architecture-evaluation-part-3-of-3/
> say that the silicon is vulnerable.  So, which is it?

Any thoughts about this?

thanks,

greg k-h