From: sashiko-bot@kernel.org
To: "Ricardo Robaina" <rrobaina@redhat.com>
Cc: bpf@vger.kernel.org, audit@vger.kernel.org
Subject: Re: [PATCH 03/13] arm: pass all six syscall args to audit_syscall_entry()
Date: Thu, 13 Aug 2026 17:20:57 +0000 [thread overview]
Message-ID: <20260813172057.A97BC1F00A3A@smtp.kernel.org> (raw)
In-Reply-To: <4f787a0c2a27eb919c481875b61a7467ef8ce547.1786626275.git.rrobaina@redhat.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
New issues:
- [High] The patch series changes the signature of `audit_syscall_entry()` globally but fails to update numerous architectures, breaking their builds.
Pre-existing issues:
- [High] A tracer can bypass seccomp filters on ARM by modifying `ARM_r0` via ptrace, as seccomp incorrectly evaluates the unmodified `ARM_ORIG_r0`.
--
--- Patch [3]: [PATCH 03/13] arm: pass all six syscall args to audit_syscall_entry() ---
commit 5e37711667e9af11aeb7334ef9ee7ed66cadd89d
Author: Ricardo Robaina <rrobaina@redhat.com>
arm: pass all six syscall args to audit_syscall_entry()
Update the audit_syscall_entry() call to forward the 5th and 6th
syscall arguments (ARM_r4, ARM_r5) now that the audit core logs
all six.
> diff --git a/arch/arm/kernel/ptrace.c b/arch/arm/kernel/ptrace.c
> index 7951b2c06fec6..ace74207738d0 100644
> --- a/arch/arm/kernel/ptrace.c
> +++ b/arch/arm/kernel/ptrace.c
> @@ -869,7 +869,7 @@ asmlinkage int syscall_trace_enter(struct pt_regs *regs)
[Severity: High]
This is a pre-existing issue, but can a tracer bypass seccomp filters here?
The ptrace intercept occurs before seccomp:
arch/arm/kernel/ptrace.c:syscall_trace_enter() {
...
if (test_thread_flag(TIF_SYSCALL_TRACE))
report_syscall(regs, PTRACE_SYSCALL_ENTER);
#ifdef CONFIG_HAVE_ARCH_SECCOMP_FILTER
if (secure_computing() == -1)
return -1;
...
}
If the tracer modifies the tracee's first syscall argument (ARM_r0) via
ptrace, does seccomp evaluate the unmodified ARM_ORIG_r0 instead?
arch/arm/include/asm/syscall.h:syscall_get_arguments() {
...
args[0] = regs->ARM_ORIG_r0;
...
}
Could this allow restricted system calls to be executed with arbitrary first
arguments?
> trace_sys_enter(regs, scno);
>
> audit_syscall_entry(scno, regs->ARM_r0, regs->ARM_r1, regs->ARM_r2,
> - regs->ARM_r3);
> + regs->ARM_r3, regs->ARM_r4, regs->ARM_r5);
[Severity: High]
Does this patch series break the build for other architectures?
The series changes the signature of audit_syscall_entry() globally to require
7 arguments instead of 5:
include/linux/audit.h:
static inline void audit_syscall_entry(int major, unsigned long a0,
unsigned long a1, unsigned long a2,
unsigned long a3, unsigned long a4,
unsigned long a5)
Are other architectures like arm64 still calling it with 5 arguments?
arch/arm64/kernel/ptrace.c:syscall_trace_enter() {
...
audit_syscall_entry(regs->syscallno, regs->orig_x0, regs->regs[1],
regs->regs[2], regs->regs[3]);
...
}
Will this result in too few arguments to function compiler errors for
architectures that do not use generic entry?
>
> return scno;
> }
--
Sashiko AI review · https://sashiko.dev/#/patchset/cover.1786626275.git.rrobaina@redhat.com?part=3
next prev parent reply other threads:[~2026-08-13 17:20 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-13 17:02 [PATCH 00/13] audit: log all six syscall arguments in the SYSCALL record Ricardo Robaina
2026-08-13 17:02 ` [PATCH 01/13] " Ricardo Robaina
2026-08-13 17:20 ` sashiko-bot
2026-08-13 17:02 ` [PATCH 02/13] alpha: pass all six syscall args to audit_syscall_entry() Ricardo Robaina
2026-08-13 17:18 ` sashiko-bot
2026-08-13 17:02 ` [PATCH 03/13] arm: " Ricardo Robaina
2026-08-13 17:20 ` sashiko-bot [this message]
2026-08-13 17:02 ` [PATCH 04/13] arm64: " Ricardo Robaina
2026-08-13 17:17 ` sashiko-bot
2026-08-13 17:02 ` [PATCH 05/13] csky: " Ricardo Robaina
2026-08-13 17:16 ` sashiko-bot
2026-08-13 17:02 ` [PATCH 06/13] microblaze: " Ricardo Robaina
2026-08-13 17:15 ` sashiko-bot
2026-08-13 17:02 ` [PATCH 07/13] mips: " Ricardo Robaina
2026-08-13 17:15 ` sashiko-bot
2026-08-13 17:02 ` [PATCH 08/13] openrisc: " Ricardo Robaina
2026-08-13 17:20 ` sashiko-bot
2026-08-13 17:02 ` [PATCH 09/13] parisc: " Ricardo Robaina
2026-08-13 17:13 ` sashiko-bot
2026-08-13 17:03 ` [PATCH 10/13] sh: " Ricardo Robaina
2026-08-13 17:24 ` sashiko-bot
2026-08-13 17:03 ` [PATCH 11/13] sparc64: " Ricardo Robaina
2026-08-13 17:26 ` sashiko-bot
2026-08-13 17:03 ` [PATCH 12/13] um: " Ricardo Robaina
2026-08-13 17:19 ` sashiko-bot
2026-08-13 17:03 ` [PATCH 13/13] xtensa: " Ricardo Robaina
2026-08-13 17:23 ` sashiko-bot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260813172057.A97BC1F00A3A@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=audit@vger.kernel.org \
--cc=bpf@vger.kernel.org \
--cc=rrobaina@redhat.com \
--cc=sashiko-reviews@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.