[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250116152137.GE21801@redhat.com>
Date: Thu, 16 Jan 2025 16:21:38 +0100
From: Oleg Nesterov <oleg@...hat.com>
To: "Dmitry V. Levin" <ldv@...ace.io>
Cc: Eugene Syromyatnikov <evgsyr@...il.com>,
Mike Frysinger <vapier@...too.org>,
Renzo Davoli <renzo@...unibo.it>,
Davide Berardi <berardi.dav@...il.com>,
strace-devel@...ts.strace.io, linux-kernel@...r.kernel.org,
linux-api@...r.kernel.org
Subject: Re: [PATCH v2 6/7] ptrace: introduce PTRACE_SET_SYSCALL_INFO request
On 01/13, Dmitry V. Levin wrote:
>
> +static int
> +ptrace_set_syscall_info(struct task_struct *child, unsigned long user_size,
> + void __user *datavp)
> +{
> + struct pt_regs *regs = task_pt_regs(child);
> + struct ptrace_syscall_info info;
> + int error;
> +
> + BUILD_BUG_ON(sizeof(struct ptrace_syscall_info) < PTRACE_SYSCALL_INFO_SIZE_VER0);
> +
> + if (user_size < PTRACE_SYSCALL_INFO_SIZE_VER0 || user_size > PAGE_SIZE)
> + return -EINVAL;
> +
> + error = copy_struct_from_user(&info, sizeof(info), datavp, user_size);
OK, I certainly can't understand why copy_struct_from_user/check_zeroed_user
is useful, at least in this case. In particular, this won't allow to run the
new code (which uses the "extended" ptrace_syscall_info) on the older kernels?
Can't we just use user_size as a version number?
We can also turn info->reserved into info->version filled by
ptrace_get_syscall_info().
ptrace_set_syscall_info() can check that info->version matches user_size.
Oleg.
Powered by blists - more mailing lists