Re: [PATCH v2 10/13] sh: pass pt_regs to audit_syscall_entry()

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [Critical] Syscall spoofing vulnerability: trace_sys_enter() logs the user-controlled 5th argument instead of the true syscall ID.
--

commit 54980eef37cc5d7ecba9111c6a7139474010c424
Author: Ricardo Robaina <rrobaina@redhat.com>

sh: pass pt_regs to audit_syscall_entry()

audit_syscall_entry() now takes a pointer to pt_regs and extracts the syscall
arguments itself via syscall_get_arguments(). This commit drops the individual
argument registers from the call and passes regs instead.

> diff --git a/arch/sh/kernel/ptrace_32.c b/arch/sh/kernel/ptrace_32.c
> index 8794081483fbd..e138f529ee7ec 100644
> --- a/arch/sh/kernel/ptrace_32.c
> +++ b/arch/sh/kernel/ptrace_32.c
> @@ -466,8 +466,7 @@ asmlinkage long do_syscall_trace_enter(struct pt_regs *regs)
>  	if (unlikely(test_thread_flag(TIF_SYSCALL_TRACEPOINT)))
>  		trace_sys_enter(regs, regs->regs[0]);

[Severity: Critical]
This isn't a bug introduced by this patch, but it appears there is a
critical pre-existing issue here in do_syscall_trace_enter().

Could trace_sys_enter() be logging the wrong syscall ID?

On SH32, the actual syscall number is in regs->regs[3], while regs->regs[0]
contains the 5th argument, which is a user-controlled value.

Because do_syscall_trace_enter() passes regs->regs[0] to trace_sys_enter(), a
user-space application might be able to invoke a malicious syscall (like
execve) while populating the 5th argument register with a benign syscall ID.

Does this mismatch allow attackers to execute one syscall while security
monitors log another, potentially bypassing eBPF and ftrace monitors?

> -	audit_syscall_entry(regs->regs[3], regs->regs[4], regs->regs[5],
> -			    regs->regs[6], regs->regs[7]);
> +	audit_syscall_entry(regs->regs[3], regs);
>  
>  	return 0;
>  }

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/cover.1788351089.git.rrobaina@redhat.com?part=10