[PATCH v15 01/11] entry: Fix potential syscall truncation in syscall_trace_enter()

Linus Walleij linusw at kernel.org
Wed May 27 05:21:20 PDT 2026


On Mon, May 11, 2026 at 11:21 AM Jinjie Ruan <ruanjinjie at huawei.com> wrote:

> In syscall_trace_enter(), the current logic returns "ret ? : syscall".
> While __secure_computing() currently only returns 0 (allow) or -1 (kill),
> this "ret ? : syscall" pattern is conceptually flawed.
>
> If __secure_computing() were to return a non-zero value that isn't -1, it
> would unintentionally override the actual system call number. This logic
> is redundant because if seccomp denies the syscall, the execution path
> should already be handled by the caller based on the error return, rather
> than conflating the return code with the syscall number.
>
> Fix it by explicitly returning the syscall number. This ensures
> the syscall register remains untainted by the trace return values and
> aligns with the expectation that seccomp-related interceptions are
> handled via the -1 return status.
>
> Cc: Thomas Gleixner <tglx at kernel.org>
> Fixes: 142781e108b1 ("entry: Provide generic syscall entry functionality")
> Signed-off-by: Jinjie Ruan <ruanjinjie at huawei.com>

Reviewed-by: Linus Walleij <linusw at kernel.org>

This looks like something tglx should apply directly if generic entry on
arm64 is not progressing this merge window. Thomas?

Yours,
Linus Walleij



More information about the linux-arm-kernel mailing list