Re: [PATCH] ptrace: reject out of range error values in PTRACE_SET_SYSCALL_INFO

[Bradley Morgan]

On 14 November 2026 18:48:40 GMT, Renzo Davoli <renzo@xxxxxxxxxxx> wrote:
>When PTRACE_SET_SYSCALL_INFO is used with op == PTRACE_SYSCALL_INFO_EXIT
>and is_error set, info.exit.rval is passed to syscall_set_return_value()
>as its "int error" argument.  The only check is that rval fits in a
>"long", which is a no-op on 64-bit architectures, so:
>
> - values outside the "int" range are silently truncated;
> - a value whose low 32 bits are zero, e.g. 0 or 0x100000000, becomes
>   error == 0, and the system call returns 0 as a success although the
>   tracer asked for an error;
> - a positive value is stored as is by some architectures (e.g. x86)
>   and is not seen as an error by the tracee.
>
>PTRACE_GET_SYSCALL_INFO reports errors as negative errno values, so
>reject with -ERANGE any error value outside [-MAX_ERRNO, -1].
>
>Fixes: 26bb32768fe6 ("ptrace: introduce PTRACE_SET_SYSCALL_INFO request")
>Signed-off-by: Renzo Davoli <renzo@xxxxxxxxxxx>
>Assisted-by: claude-opus-5-5

Drop. No longer needed. Annoyingly. Assisted bys aren't needed no more. :(

>---
>This patch is independent of the PTRACE_SET_SYSCALL_INFO syscall skipping
>series and applies cleanly either before or after it.
>
>Tested on x86_64 (QEMU/KVM) with a test program that, at the exit stop of
>getpid(), calls PTRACE_SET_SYSCALL_INFO with op ==
>PTRACE_SYSCALL_INFO_EXIT,
>is_error = 1 and the following rval values:
>
>  rval                   without this patch            with this patch
>                         (getpid() in the tracee)
>  0                      returns 0, success            -ERANGE
>  1                      returns 1, success            -ERANGE
>  ESRCH (3)              returns 3, success            -ERANGE
>  -MAX_ERRNO - 1         returns -4096, success        -ERANGE
>  INT_MIN                returns INT_MIN, success      -ERANGE
>  0x100000000            returns 0, success            -ERANGE
>  -0x100000000 - ESRCH   fails with ESRCH, but         -ERANGE
>                         PTRACE_GET_SYSCALL_INFO
>                         reports rval -3
>  -ESRCH                 fails with ESRCH              fails with ESRCH
>  -MAX_ERRNO             fails with errno 4095         fails with errno 4095
>
>Without this patch PTRACE_SET_SYSCALL_INFO succeeds in every case, and
>on x86_64 syscall_set_return_value() stores the error, truncated to
>"int", as is: values outside [-MAX_ERRNO, -1] become successful return
>values, so the tracer asks for an error and the tracee sees a success,
>or a different error than the one requested.  With this patch these
>values are rejected and the tracee registers are left untouched; valid
>errno values behave as before.

That's just word puke. I did NOT read all of that, make it TL;DR
preferably.

>
> kernel/ptrace.c | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
>diff --git a/kernel/ptrace.c b/kernel/ptrace.c
>index 3f2fe68ccb14..2fbd0d55b42e 100644
>--- a/kernel/ptrace.c
>+++ b/kernel/ptrace.c
>@@ -1111,6 +1111,14 @@ ptrace_set_syscall_info_exit(struct task_struct *child, struct pt_regs *regs,
> 	if (rval != info->exit.rval)
> 		return -ERANGE;
> 
>+	/*
>+	 * An error is passed to syscall_set_return_value() as an "int"
>+	 * and must be a negative errno value: anything else would be
>+	 * truncated or would make the system call succeed.
>+	 */

This is very verbose. Like VERY verbose. Maybe a one or two liner comment
would be way way better

>+	if (info->exit.is_error && (rval < -MAX_ERRNO || rval >= 0))
>+		return -ERANGE;
>+
> 	if (info->exit.is_error)
> 		syscall_set_return_value(child, regs, rval, 0);
> 	else
>

--- Thanks!