Re: [RFC PATCH] s390/syscall: Sign extend system call number retrieved via syscall_get_nr()

[Heiko Carstens <hca@linux.ibm.com>]

On Wed, Oct 21, 2026 at 01:27:30PM +0000, sashiko-bot@kernel.org wrote:
> > @@ -20,7 +20,7 @@ static inline long syscall_get_nr(struct task_struct *task,
> >  				  struct pt_regs *regs)
> >  {
> >  	return test_pt_regs_flag(regs, PIF_SYSCALL) ?
> > -		(regs->int_code & 0xffff) : -1;
> > +		(s16)(regs->int_code & 0xffff) : -1;
> >  }
> 
> [Severity: High]
> When a system call is skipped under SECCOMP_RET_TRACE on s390, can this cause
> __do_syscall() to return the wrong value to userspace instead of -ENOSYS?
> 
> Previously, syscall_get_nr() returned an unsigned 16-bit value (65535 when nr
> was set to -1), so after PTRACE_EVENT_SECCOMP in
> kernel/seccomp.c:__seccomp_filter():
> 
> 	/* Check if the tracer forced the syscall to be skipped. */
> 	this_syscall = syscall_get_nr(current, current_pt_regs());
> 	if (this_syscall < 0)
> 		goto skip;

This is addressed with:
https://lore.kernel.org/all/20261021085643.2442949-1-hca@linux.ibm.com/

Read: should not happen anymore.

> [Severity: Medium]
> Should arch/s390/kernel/syscall.c:__do_syscall() and
> arch/s390/include/asm/syscall.h:syscall_set_nr() also be updated to keep the
> syscall number representation consistent with syscall_get_nr()?
> 
> In arch/s390/kernel/syscall.c:__do_syscall():
> 
> 	nr = regs->int_code & 0xffff;
> 	if (likely(!nr)) {
> 		nr = regs->gprs[1] & 0xffff;
> 		regs->int_code &= ~0xffffUL;
> 		regs->int_code |= nr;
> 	}
> 	regs->gprs[2] = nr;

This is valid - things should be consistent.