On Wed, Mar 29, 2023 at 07:58:51PM +0200, Oleg Nesterov wrote: > 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. > I'm convinced now, this feels like the correct solution. I will pull your suggested patch ahead and drop the task variant of access_ok. Am I ok to add your signed-off-by to the suggested patch, and i'll add it to the series? Not quite sure what the correct set of tags is, since i don't have any suggested changes to your patch. ~Gregory
