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

[Thomas Gleixner]

On Mon, May 11 2026 at 17:20, Jinjie Ruan 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@xxxxxxxxxx>
> Fixes: 142781e108b1 ("entry: Provide generic syscall entry functionality")

What's fixed here?

A potential future change of the __secure_computing() return value
requires that _ALL_ callsites of that function have to be audited
and fixed up, no?

So the change is not a fix it's an optimization to get rid of the extra
conditional.

If you really want to sanitize this, then change the
__secure_computing() return type to boolean (true = allow, false =
fail) and fixup the two dozen or so call sites.

Thanks,

        tglx