kernel/linux.git/include/linux/entry-common.h, branch v7.3-rc1

entry, treewide: Make syscall_enter_from_user_mode[_work]() indicate syscall execution

2026-07-20T18:38:40+00:00

The return values of syscall_enter_from_user_mode[_work]() are non-intuitive. Both functions return the syscall number which should be invoked by the architecture specific syscall entry code. The returned number can be: - the unmodified syscall number which was handed in by the caller - a modified syscall number (ptrace, seccomp, trace/probe/bpf) That has an additional twist. If the return value is -1L then the caller is not allowed to modify the return value as that indicates that the modifying entity requests to abort the syscall and set the return value already. That can obviously not be differentiated from a syscall which handed in -1 as syscall number. The most trivial way to deal with that is: set_return_value(regs, -ENOSYS); nr = syscall_enter_from_user_mode(regs, nr); if (valid(nr)) handle_syscall(regs, nr); That's what LOONGARCH, RISCV, and X86 do. But PowerPC and S390 do not preset the return value, so when user space hands in -1 and there is nothing setting the return value in the entry work code, then the syscall is skipped but the return value is whatever random data has been in the return value register. Change the return values of syscall_enter_from_user_mode[_work]() to boolean and return false, when either ptrace or seccomp request to skip the syscall. If they return true, update the syscall number as it might have been changed. That results in slightly different behaviour of the architectures versus tracing. If the syscall tracepoint has probe/BPF attached, those might set the syscall number to -1 and also set the return value. PowerPC and S390 will then overwrite that value with -ENOSYS. The other architectures will just ignore it like any other invalid syscall and use the modified one. Originally-by: Michal Suchánek Signed-off-by: Thomas Gleixner Tested-by: Michal Suchánek Link: https://patch.msgid.link/20260712141346.772209074@kernel.org

entry: Make return type of syscall_trace_enter() bool

2026-07-20T18:38:40+00:00

This prepares for changing the return types of syscall_enter_from_user_mode[_work]() to bool, which in turn separates the decision of invoking the syscall from the syscall number, which might have been changed in the call by ptrace, seccomp, tracing. Signed-off-by: Thomas Gleixner Tested-by: Michal Suchánek Reviewed-by: Jinjie Ruan Link: https://patch.msgid.link/20260712141346.699072205@kernel.org

entry: Rework trace_syscall_enter()

2026-07-20T18:38:40+00:00

Reread the syscall number from pt_regs and stop returning the eventually modified syscall number. That moves the reread to the end of syscall_trace_enter() and prepares for moving it to the call site. No functional change. Signed-off-by: Thomas Gleixner Tested-by: Michal Suchánek Reviewed-by: Jinjie Ruan Link: https://patch.msgid.link/20260712141346.639115923@kernel.org

entry: Rework syscall_audit_enter()

2026-07-20T18:38:40+00:00

Move it out of line and let it reread the syscall number on it's own. That makes the low level entry code denser and allows to move the reread to the call site of syscall_trace_enter() once the tracer is fixed up. To prevent the compiler from putting audit_context() out of line and thereby breaking dead code elimination, mark audit_context() __always_inline. Signed-off-by: Thomas Gleixner Tested-by: Michal Suchánek Reviewed-by: Jinjie Ruan Link: https://patch.msgid.link/20260712141346.576865340@kernel.org

entry: Fix seccomp bypass after ptrace with TSYNC

2026-07-14T14:34:07+00:00

Sashiko review pointed out the following issue. If a thread is stopped in syscall_trace_enter() for ptrace, another thread can install a seccomp filter with SECCOMP_FILTER_FLAG_TSYNC (e.g., via seccomp_attach_filter()). This will successfully set SYSCALL_WORK_SECCOMP on the stopped thread, but syscall_trace_enter() evaluates a cached 'work' variable sampled on entry. Consequently, the subsequent check for SYSCALL_WORK_SECCOMP misses the newly assigned flag, and the filter is silently bypassed. This race condition could allow an unprivileged process to execute a prohibited system call (e.g., execve) that the newly installed filter was intended to block, especially since the tracer might have modified the system call number during the ptrace stop. Fix this by re-reading the syscall_work flags after ptrace handling, so that any new SYSCALL_WORK_SECCOMP flag set by another thread via TSYNC during the ptrace stop is observed before the subsequent seccomp check. Fixes: 142781e108b1 ("entry: Provide generic syscall entry functionality") Signed-off-by: Jinjie Ruan Signed-off-by: Thomas Gleixner Cc: stable@vger.kernel.org Link: https://lore.kernel.org/all/20260629132914.1135C1F000E9@smtp.kernel.org/ Link: https://patch.msgid.link/20260713025712.416366-1-ruanjinjie@huawei.com

ptrace, treewide: Rename ptrace_report_syscall_entry() to ptrace_report_syscall_permit_entry()

2026-07-12T10:38:02+00:00

The return value of that function is boolean and tells the caller whether to permit the syscall processing or not. Rename the function so the purpose is clear and make the return type bool. Signed-off-by: Thomas Gleixner Tested-by: Mukesh Kumar Chaurasiya (IBM) Reviewed-by: Jinjie Ruan Reviewed-by: Radu Rendec Reviewed-by: Mukesh Kumar Chaurasiya (IBM) Acked-by: Oleg Nesterov Acked-by: Magnus Lindholm Link: https://patch.msgid.link/20260707190254.280015701@kernel.org

seccomp, treewide: Rename and convert __secure_computing() to return boolean

2026-07-12T10:38:02+00:00

The return value of __secure_computing() currently uses 0 to indicate that a system call should be allowed, and -1 to indicate that it should be blocked/killed. This 0/-1 pattern is non-intuitive for a security check function and makes the control flow at the call sites less readable. Furthermore, any potential future changes to these return values would require a high-risk, error-prone audit of all its users across different architectures. Sanitize this logic by converting the return type of __secure_computing() to a proper boolean, where 'true' explicitly means 'allow' and 'false' means 'fail/deny'. Update all the two dozen or so call sites across the tree to align with this new boolean semantic. No functional changes are intended, as the callers still return -1 to the lower-level assembly entry code upon seccomp denial. Rename the function to __seccomp_permit_syscall() so that the purpose is entirely clear. [ tglx: Rename the function ] Suggested-by: Thomas Gleixner Suggested-by: Mark Rutland Signed-off-by: Jinjie Ruan Signed-off-by: Thomas Gleixner Tested-by: Mukesh Kumar Chaurasiya (IBM) Reviewed-by: Mukesh Kumar Chaurasiya (IBM) Acked-by: Oleg Nesterov Link: https://patch.msgid.link/20260707190254.230735780@kernel.org

entry: Use syscall number instead of rereading it

2026-07-12T10:38:01+00:00

rseq_syscall_enter_work() is invoked before the syscall number can be modified. So there is no point in rereading it from pt_regs. Signed-off-by: Thomas Gleixner Tested-by: Mukesh Kumar Chaurasiya (IBM) Reviewed-by: Radu Rendec Reviewed-by: Jinjie Ruan Reviewed-by: Mukesh Kumar Chaurasiya (IBM) Reviewed-by: Philippe Mathieu-Daudé Link: https://patch.msgid.link/20260707190254.181086755@kernel.org

entry: Remove syscall_enter_from_user_mode()

2026-07-12T10:38:01+00:00

All architecture use either: nr = syscall_enter_from_user_mode_randomize_stack(regs, nr); or enter_from_user_mode_randomize_stack(regs); nr = syscall_enter_from_user_mode_work(regs, nr); Remove the now unused function. Signed-off-by: Thomas Gleixner Tested-by: Mukesh Kumar Chaurasiya (IBM) Reviewed-by: Jinjie Ruan Reviewed-by: Mukesh Kumar Chaurasiya (IBM) Link: https://patch.msgid.link/20260707190254.132654198@kernel.org

entry: Provide [syscall_]enter_from_user_mode_randomize_stack()

2026-07-12T10:38:01+00:00

Randomizing the syscall stack can only happen after state is established via enter_from_user_mode() or syscall_enter_from_user_mode(). The earlier it happens the better. Provide two new macros to consolidate that: - enter_from_user_mode_randomize_stack() enter_from_user_mode(); add_random_kstack_offset_irqsoff(); - syscall_enter_from_user_mode_randomize_stack() enter_from_user_mode_randomize_stack(); syscall_enter_from_user_mode_work(); to reduce boiler plate code. Those are macros and not inline functions as the latter would limit the stack randomization scope to the inline function itself. Signed-off-by: Thomas Gleixner Tested-by: Mukesh Kumar Chaurasiya (IBM) Reviewed-by: Radu Rendec Reviewed-by: Jinjie Ruan Reviewed-by: Philippe Mathieu-Daudé Reviewed-by: Mukesh Kumar Chaurasiya (IBM) Link: https://patch.msgid.link/20260707190253.816918647@kernel.org