Re: [PATCH 11/13] sparc64: 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] 32-bit compat syscall arguments are not zero-extended before being passed to audit_syscall_entry(), leading to a high-severity audit evasion vulnerability for socketcall multiplexed syscalls.
--

--- Patch [11]: [PATCH 11/13] sparc64: pass all six syscall args to audit_syscall_entry() ---
commit 5c60aff4dd1af29adf66c85f200b0a80fe2238fb
Author: Ricardo Robaina <rrobaina@redhat.com>

sparc64: pass all six syscall args to audit_syscall_entry()

This commit updates syscall_trace_enter() to forward the 5th and 6th syscall
arguments (UREG_I4, UREG_I5) to audit_syscall_entry(). This change ensures
all six arguments are passed, aligning with the audit core's expectations.

> diff --git a/arch/sparc/kernel/ptrace_64.c b/arch/sparc/kernel/ptrace_64.c
> index 9fc67fa9336fe..d0ad3200d789c 100644
> --- a/arch/sparc/kernel/ptrace_64.c
> +++ b/arch/sparc/kernel/ptrace_64.c
> @@ -1100,7 +1100,8 @@ asmlinkage int syscall_trace_enter(struct pt_regs *regs)
>  
>  	audit_syscall_entry(regs->u_regs[UREG_G1], regs->u_regs[UREG_I0],
>  			    regs->u_regs[UREG_I1], regs->u_regs[UREG_I2],
> -			    regs->u_regs[UREG_I3]);
> +			    regs->u_regs[UREG_I3], regs->u_regs[UREG_I4],
> +			    regs->u_regs[UREG_I5]);

[Severity: High]
This isn't a bug introduced by this patch, but is it possible for a 32-bit
compat process to evade audit rules because these arguments are not
zero-extended?

For a 32-bit process executing a multiplexed system call like socketcall,
an attacker could intentionally leave non-zero garbage in the upper 32 bits of
the registers. 

Because syscall_trace_enter() passes the raw 64-bit values directly from
regs->u_regs without zero-extending them, the audit subsystem stores the full
64-bit value. When the audit core later evaluates rules (e.g., checking
ctx->argv[0] == SYS_BIND), the comparison fails due to the upper 32-bit
garbage, bypassing the rule.

Since the SPARC64 assembly later zero-extends the arguments before invoking the
actual compat syscall handler, the syscall succeeds without being properly
audited.

Could we zero-extend these register values for 32-bit compat tasks before
passing them to audit_syscall_entry() to prevent this bypass?

>  
>  	return ret;
>  }

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