From: sashiko-bot@kernel.org
To: "Ricardo Robaina" <rrobaina@redhat.com>
Cc: audit@vger.kernel.org, bpf@vger.kernel.org
Subject: Re: [PATCH 02/13] alpha: pass all six syscall args to audit_syscall_entry()
Date: Thu, 13 Aug 2026 17:18:56 +0000 [thread overview]
Message-ID: <20260813171856.B0E591F000E9@smtp.kernel.org> (raw)
In-Reply-To: <7dec380a50e3db536bdec61a33b8f3b2e2e7ec65.1786626275.git.rrobaina@redhat.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] When a syscall is skipped by seccomp or ptrace, the kernel fails to set the return value to -ENOSYS, allowing unprivileged userspace to spoof successful syscall returns.
--
--- Patch [2]: [PATCH 02/13] alpha: pass all six syscall args to audit_syscall_entry() ---
commit 34becaec07c6a7a08cc6bd923c1a39f3ee655963
Author: Ricardo Robaina <rrobaina@redhat.com>
Subject: alpha: pass all six syscall args to audit_syscall_entry()
Update the audit_syscall_entry() call to forward the 5th and 6th syscall
arguments. This ensures the audit core logs all six arguments on alpha.
> diff --git a/arch/alpha/kernel/ptrace.c b/arch/alpha/kernel/ptrace.c
> index 0687760ea4669..d90e2194b5284 100644
> --- a/arch/alpha/kernel/ptrace.c
> +++ b/arch/alpha/kernel/ptrace.c
> @@ -396,7 +396,8 @@ asmlinkage unsigned long syscall_trace_enter(void)
[Severity: High]
This is a pre-existing issue, but does the -ENOSYS fixup in
syscall_trace_enter() get skipped incorrectly when a syscall is filtered by
seccomp or ptrace?
Earlier in this function, the fixup condition is:
if (secure_computing() == -1) {
if (regs->r19 == 0 && regs->r0 == (unsigned long)-1)
syscall_set_return_value(current, regs, -ENOSYS, 0);
syscall_set_nr(current, regs, -1);
return -1UL;
}
If secure_computing() returns -1 to skip the syscall execution,
syscall_set_nr() sets r1 to -1. However, it seems r0 still contains the
original syscall number instead of -1. Doesn't this cause the fallback
condition to evaluate to false and skip setting -ENOSYS?
If so, a seccomp filter that skips a syscall without explicitly setting a
return value (such as SECCOMP_RET_USER_NOTIF) might leak the syscall number
back to user space as a successful return value instead of returning an error.
It looks like this same logic is mirrored in arch/alpha/kernel/entry.S in
SYSCALL_SKIP_RETURN_RESTART_GATE:
ldq $20, 0($sp) /* r0 */
lda $21, -1($31)
cmpeq $20, $21, $22
beq $22, 1f /* r0 != -1 => skip fixup */
Does this also bypass the fixup for the same reason?
>
> #ifdef CONFIG_AUDITSYSCALL
> audit_syscall_entry(syscall_get_nr(current, regs),
> - regs->r16, regs->r17, regs->r18, regs->r19);
> + regs->r16, regs->r17, regs->r18, regs->r19,
> + regs->r20, regs->r21);
> #endif
> return syscall_get_nr(current, regs);
> }
--
Sashiko AI review · https://sashiko.dev/#/patchset/cover.1786626275.git.rrobaina@redhat.com?part=2
next prev parent reply other threads:[~2026-08-13 17:18 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 [this message]
2026-08-13 17:02 ` [PATCH 03/13] arm: " Ricardo Robaina
2026-08-13 17:20 ` sashiko-bot
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=20260813171856.B0E591F000E9@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.