From: "Mukesh Kumar Chaurasiya (IBM)" <mkchauras@gmail.com>
To: maddy@linux.ibm.com, mpe@ellerman.id.au, npiggin@gmail.com,
chleroy@kernel.org, mkchauras@linux.ibm.com,
sshegde@linux.ibm.com, ryan.roberts@arm.com,
ruanjinjie@huawei.com, mkchauras@gmail.com,
linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org
Cc: "Michal Suchánek" <msuchanek@suse.de>
Subject: [PATCH V2] powerpc/syscall: Fix seccomp errno handling with GENERIC_ENTRY
Date: Mon, 29 Jun 2026 23:59:46 +0530 [thread overview]
Message-ID: <20260629182946.419552-1-mkchauras@gmail.com> (raw)
After enabling GENERIC_ENTRY on PowerPC, seccomp filters using
SCMP_ACT_ERRNO without an explicit errnoRet value return ENOSYS
(Function not implemented) instead of the expected EPERM (Operation
not permitted).
The issue occurs in system_call_exception() when syscall_enter_from_user_mode()
returns -1 to indicate the syscall should be skipped (e.g., blocked by seccomp).
The current code treats this -1 as a syscall number and compares it against
NR_syscalls. Since -1 is greater than NR_syscalls,
the code incorrectly returns -ENOSYS, overwriting the errno that seccomp
already set via syscall_set_return_value().
The generic entry code in syscall_trace_enter() calls __secure_computing(),
which sets the appropriate errno in regs->gpr[3] and returns -1 to signal
that the syscall should be skipped. However, the PowerPC syscall handler
was not checking for this -1 return value before validating the syscall
number.
Fix this by explicitly checking if syscall_enter_from_user_mode() returns
-1 and returning the value already set in regs->gpr[3] (the errno from
seccomp) before performing the syscall number validation.
Also Move the syscall_enter_from_user_mode() call and the seccomp/ptrace
skip check to after the NR_syscalls bounds check.
When syscall -1 was passed, the r0 == -1L check would trigger before
the NR_syscalls check, causing syscall_get_error() to return 0 instead
of -ENOSYS. This resulted in a silent success (ret=0, errno=0) instead
of the expected ENOSYS error.
By moving syscall_enter_from_user_mode() after the bounds check, an
initial syscall number of -1 is correctly rejected with -ENOSYS first.
The seccomp/ptrace skip path still works correctly for valid syscall
numbers that get overridden to -1 by seccomp or ptrace.
This aligns PowerPC's behavior with other architectures using GENERIC_ENTRY
and restores correct seccomp errno handling.
Fixes: bee25f97ad24 ("powerpc: Enable GENERIC_ENTRY feature")
Reported-by: Michal Suchánek <msuchanek@suse.de>
Closes: https://lore.kernel.org/all/ajpp-_XnbF3UTM_E@kunlun.suse.cz/
Signed-off-by: Mukesh Kumar Chaurasiya (IBM) <mkchauras@gmail.com>
---
v1 -> v2:
- Fix issues in the previous fix (Michal)
v1: https://lore.kernel.org/all/20260624171520.772408-1-mkchauras@gmail.com
arch/powerpc/kernel/syscall.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/kernel/syscall.c b/arch/powerpc/kernel/syscall.c
index a9da2af6efa8..36d73933a311 100644
--- a/arch/powerpc/kernel/syscall.c
+++ b/arch/powerpc/kernel/syscall.c
@@ -20,7 +20,6 @@ notrace long system_call_exception(struct pt_regs *regs, unsigned long r0)
syscall_fn f;
add_random_kstack_offset();
- r0 = syscall_enter_from_user_mode(regs, r0);
if (unlikely(r0 >= NR_syscalls)) {
if (unlikely(trap_is_unsupported_scv(regs))) {
@@ -31,6 +30,12 @@ notrace long system_call_exception(struct pt_regs *regs, unsigned long r0)
return -ENOSYS;
}
+ r0 = syscall_enter_from_user_mode(regs, r0);
+
+ /* Seccomp or ptrace may have set return value, skip syscall */
+ if (unlikely(r0 == -1L))
+ return syscall_get_error(current, regs);
+
/* May be faster to do array_index_nospec? */
barrier_nospec();
--
2.54.0
next reply other threads:[~2026-06-29 18:29 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-29 18:29 Mukesh Kumar Chaurasiya (IBM) [this message]
2026-06-30 17:19 ` [PATCH V2] powerpc/syscall: Fix seccomp errno handling with GENERIC_ENTRY Michal Suchánek
2026-06-30 20:11 ` Shrikanth Hegde
2026-07-01 6:27 ` Mukesh Kumar Chaurasiya
2026-07-01 7:41 ` Michal Suchánek
2026-07-01 8:01 ` Michal Suchánek
2026-07-01 8:29 ` Michal Suchánek
2026-07-02 5:50 ` Mukesh Kumar Chaurasiya
2026-07-02 9:34 ` Michal Suchánek
2026-07-02 9:39 ` Mukesh Kumar Chaurasiya
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=20260629182946.419552-1-mkchauras@gmail.com \
--to=mkchauras@gmail.com \
--cc=chleroy@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=maddy@linux.ibm.com \
--cc=mkchauras@linux.ibm.com \
--cc=mpe@ellerman.id.au \
--cc=msuchanek@suse.de \
--cc=npiggin@gmail.com \
--cc=ruanjinjie@huawei.com \
--cc=ryan.roberts@arm.com \
--cc=sshegde@linux.ibm.com \
/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.