[PATCH v17 15/15] arm64: vdso: Expose sigreturn address on vdso to the kernel

Mark Rutland mark.rutland at arm.com
Wed Jul 22 11:18:59 PDT 2026


On Tue, Jul 21, 2026 at 10:55:03AM +0200, Linus Walleij wrote:
> On Tue, Jul 21, 2026 at 10:19 AM Jinjie Ruan <ruanjinjie at huawei.com> wrote:
> 
> > Syscall User Dispatch (SUD) must not intercept the signal trampoline
> > code, otherwise returning from a signal with a locked selector may
> > cause infinite recursion into the signal handler.
> >
> > Provide an arm64 implementation of arch_syscall_is_vdso_sigreturn()
> > to exclude these sigreturn syscalls from dispatch.
> >
> > For native 64-bit tasks, check whether the current PC matches the 'svc #0'
> > instruction inside the vDSO sigreturn trampoline (defined in
> > arch/arm64/kernel/vdso/sigreturn.S as below).
> >
> >         SYM_CODE_START(__kernel_rt_sigreturn)
> >                 mov     x8, #__NR_rt_sigreturn
> >                 svc     #0
> >         SYM_CODE_END(__kernel_rt_sigreturn)
> >
> > For COMPAT tasks, verify that the instruction falls within the dedicated
> > 'sigpage' range, since compat signal handlers use this architecture-
> > specific page (not the vDSO) for their return trampoline. This prevents
> > SUD from incorrectly dispatching syscalls issued during signal return.
> >
> > Suggested-by: Thomas Weißschuh <thomas.weissschuh at linutronix.de>
> > Suggested-by: Kevin Brodsky <kevin.brodsky at arm.com>
> > Suggested-by: kemal <kmal at cock.li>
> > Signed-off-by: Jinjie Ruan <ruanjinjie at huawei.com>
> 
> I'm a bit scared about SUD.
> 
> Certainly we can merge patches 1-14 first and iron out
> any trouble related to that and split this off so a separate
> series to be applied lated?

I had already asked Jinie to drop SUD back in v14, and he had agreed:

  https://lore.kernel.org/lkml/akegeU59jSK9t7FX@J2N7QTR9R3/
  https://lore.kernel.org/lkml/3ac6d4be-7c57-44c2-80a0-408e2c6f8136@huawei.com/

Jinjie, please drop this for now, as we had _already_ agreed.

I will look over the rest of the series soon.

Mark.



More information about the linux-arm-kernel mailing list