Re: [PATCH 10/13] sh: pass all six syscall args 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:
- [High] This problem wasn't introduced by this patch, but the `sys_enter` tracepoint is incorrectly invoked with the 5th syscall argument (`regs->regs[0]`) instead of the system call number, allowing userspace to spoof syscall trace events.
--

--- Patch [10]: [PATCH 10/13] sh: pass all six syscall args to audit_syscall_entry() ---
commit 3f32d157a274ce4c78e2758720926d9048ca177a
Author: Ricardo Robaina <rrobaina@redhat.com>

sh: pass all six syscall args to audit_syscall_entry()

This commit updates the audit_syscall_entry() call to forward the 5th
and 6th syscall arguments. This aligns with the audit core which now
logs all six arguments.

> diff --git a/arch/sh/kernel/ptrace_32.c b/arch/sh/kernel/ptrace_32.c
> index 06f765d71a295..3efefd67b457c 100644
> --- a/arch/sh/kernel/ptrace_32.c
> +++ b/arch/sh/kernel/ptrace_32.c
> @@ -467,7 +467,8 @@ asmlinkage long do_syscall_trace_enter(struct pt_regs *regs)
>  		trace_sys_enter(regs, regs->regs[0]);

[Severity: High]
This is a pre-existing issue in do_syscall_trace_enter(), but is
trace_sys_enter() receiving the correct system call number here?

Since regs->regs[0] holds the 5th syscall argument on SuperH, passing it
here means security monitoring tools attached to the sys_enter tracepoint
might receive an incorrect, user-controlled syscall number. Could a local
unprivileged attacker exploit this by placing a sensitive syscall number
in the actual syscall register and a benign one in r0 to bypass security
auditing?

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

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