Re: [PATCH 12/13] um: 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:
- [Low] The patch series changes the signature of `audit_syscall_entry()` globally but splits caller updates into separate commits and completely misses updating the PowerPC and Xtensa architectures, causing a tree-wide build failure.
--

--- Patch [12]: [PATCH 12/13] um: pass all six syscall args to audit_syscall_entry() ---
commit 9c50f8d1e9a5a601156f9a077df794dd83a368a0
Author: Ricardo Robaina <rrobaina@redhat.com>

um: pass all six syscall args to audit_syscall_entry()

This commit updates the syscall_trace_enter function in the UML architecture
to pass the 5th and 6th syscall arguments to audit_syscall_entry. This aligns
with the new audit core API which logs all six arguments.

> diff --git a/arch/um/kernel/ptrace.c b/arch/um/kernel/ptrace.c
> --- a/arch/um/kernel/ptrace.c
> +++ b/arch/um/kernel/ptrace.c
[ ... ]
> @@ -127,7 +127,9 @@ int syscall_trace_enter(struct pt_regs *regs)
>  			    UPT_SYSCALL_ARG1(&regs->regs),
>  			    UPT_SYSCALL_ARG2(&regs->regs),
>  			    UPT_SYSCALL_ARG3(&regs->regs),
> -			    UPT_SYSCALL_ARG4(&regs->regs));
> +			    UPT_SYSCALL_ARG4(&regs->regs),
> +			    UPT_SYSCALL_ARG5(&regs->regs),
> +			    UPT_SYSCALL_ARG6(&regs->regs));

[Severity: Low]
Does splitting the caller updates into separate commits from the core API
change break bisection for architectures not using the generic entry code?

If the core API was changed in a previous commit, building this intermediate
commit during git bisect will fail since architectures not yet updated will
have callers expecting the old signature.

Additionally, were the PowerPC and Xtensa architectures missed entirely in
this series? For example, do_syscall_trace_enter() in
arch/powerpc/kernel/ptrace/ptrace.c still passes 5 arguments instead of the
required 7:

		audit_syscall_entry(regs->gpr[0], regs->gpr[3], regs->gpr[4],
				    regs->gpr[5], regs->gpr[6]);

A similar issue occurs in do_syscall_trace_enter() in
arch/xtensa/kernel/ptrace.c. Will this cause an unconditional build failure
for these architectures when compiled with CONFIG_AUDITSYSCALL=y?

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