On 03/29, Gregory Price wrote: > > On Wed, Mar 29, 2023 at 07:13:22PM +0200, Oleg Nesterov wrote: > > > > - if (selector && !access_ok(selector, sizeof(*selector))) > > - return -EFAULT; > > - > > break; > > default: > > return -EINVAL; > > > > The result of this would be either a task calling via prctl or a tracer > calling via ptrace would be capable of setting selector to a bad pointer > and producing a SIGSEGV on the next system call. Yes, > It's a pretty small footgun, but maybe that's reasonable? I hope this is reasonable, > From a user perspective, debugging this behavior would be nightmarish. > Your call to prctl/ptrace would succeed and the process would continue > to execute until the next syscall - at which point you incur a SIGSEGV, Yes. But how does this differ from the case when, for example, user does prtcl(PR_SET_SYSCALL_USER_DISPATCH, selector = 1) ? Or another bad address < TASK_SIZE? access_ok() will happily succeed, then later syscall_user_dispatch() will equally trigger SIGSEGV. Oleg.
