[PATCH] LoongArch: add spectre boundry for syscall dispatch table

[PATCH] LoongArch: add spectre boundry for syscall dispatch table

[Greg Kroah-Hartman]

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

Re: [PATCH] LoongArch: add spectre boundry for syscall dispatch table

[Xi Ruoyao]

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>

Re: [PATCH] LoongArch: add spectre boundry for syscall dispatch table

[Greg Kroah-Hartman]

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

Re: [PATCH] LoongArch: add spectre boundry for syscall dispatch table

[Greg Kroah-Hartman]

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

Re: [PATCH] LoongArch: add spectre boundry for syscall dispatch table

[Bibo Mao]

On 2026/4/2 下午10:36, Greg Kroah-Hartman wrote:
> 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?
co-ask though it is hard to decide :(

Regards
Bibo Mao
> 
> thanks,
> 
> greg k-h
> 

Re: [PATCH] LoongArch: add spectre boundry for syscall dispatch table

[Greg Kroah-Hartman]

On Wed, Apr 08, 2026 at 09:17:07AM +0800, Bibo Mao wrote:
> 
> 
> On 2026/4/2 下午10:36, Greg Kroah-Hartman wrote:
> > 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?
> co-ask though it is hard to decide :(

Can't you all run the reproducers on your platform to determine this?
There should be some basic ones around somewhere, this is a very old bug
:)

thanks,

greg k-h

Re: [PATCH] LoongArch: add spectre boundry for syscall dispatch table

[Huacai Chen]

Hi, all,

On Wed, Apr 8, 2026 at 1:26 PM Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
>
> On Wed, Apr 08, 2026 at 09:17:07AM +0800, Bibo Mao wrote:
> >
> >
> > On 2026/4/2 下午10:36, Greg Kroah-Hartman wrote:
> > > 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?
> > co-ask though it is hard to decide :(
>
> Can't you all run the reproducers on your platform to determine this?
> There should be some basic ones around somewhere, this is a very old bug
> :)
I have consulted with the chip designers. They confirmed that existing
LoongArch processors are vulnerable to Spectre-V1. But this conclusion
is just for the PoC (as [1] said,  Spectre-V1 is not easily mitigated
in hardware), it is very difficult to create a real attack program.
This is not even a LoongArch-specific problem.

As an additional point, LoongArch's boundary-checking memory access
instructions, which provide immunity against Spectre-V1, are not
convenient enough to automatically apply to all critical code
sections.

Anyway, user pointer sanitization is the proper mitigation of
Spectre-V1, and that is exactly what this patch does. So, I will take
this patch and update other corresponding parts of the kernel.

[1] https://cc-sw.com/chinese-loongarch-architecture-evaluation-part-3-of-3/

Huacai

>
> thanks,
>
> greg k-h

Re: [PATCH] LoongArch: add spectre boundry for syscall dispatch table

[Xi Ruoyao]

On Wed, 2026-04-08 at 16:20 +0800, Huacai Chen wrote:
> Hi, all,
> 
> On Wed, Apr 8, 2026 at 1:26 PM Greg Kroah-Hartman
> <gregkh@linuxfoundation.org> wrote:
> > 
> > On Wed, Apr 08, 2026 at 09:17:07AM +0800, Bibo Mao wrote:
> > > 
> > > 
> > > On 2026/4/2 下午10:36, Greg Kroah-Hartman wrote:
> > > > 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?
> > > co-ask though it is hard to decide :(
> > 
> > Can't you all run the reproducers on your platform to determine this?
> > There should be some basic ones around somewhere, this is a very old bug
> > :)
> I have consulted with the chip designers. They confirmed that existing
> LoongArch processors are vulnerable to Spectre-V1. But this conclusion
> is just for the PoC (as [1] said,  Spectre-V1 is not easily mitigated
> in hardware), it is very difficult to create a real attack program.
> This is not even a LoongArch-specific problem.
> 
> As an additional point, LoongArch's boundary-checking memory access
> instructions, which provide immunity against Spectre-V1, are not
> convenient enough to automatically apply to all critical code
> sections.
> 
> Anyway, user pointer sanitization is the proper mitigation of
> Spectre-V1, and that is exactly what this patch does. So, I will take
> this patch and update other corresponding parts of the kernel.
> 
> [1] https://cc-sw.com/chinese-loongarch-architecture-evaluation-part-3-of-3/

Then IMO we should update cpuinfo report as well (well, maybe also for
other architectures, if there are literally no hardware immune to the
issue).

-- 
Xi Ruoyao <xry111@xry111.site>