Re: + syscalls-x86-add-__nr_kcmp-syscall-v8.patch added to -mm tree

[Oleg Nesterov]

On 02/15, Cyrill Gorcunov wrote:
>
> On Wed, Feb 15, 2012 at 03:36:06PM +0100, Oleg Nesterov wrote:
> >
> > > +
> > > +	/*
> > > +	 * One should have enough rights to inspect task details.
> > > +	 */
> > > +	if (!ptrace_may_access(task1, PTRACE_MODE_READ) ||
> > > +	    !ptrace_may_access(task2, PTRACE_MODE_READ)) {
> > > +		ret = -EACCES;
> >
> > Well, probably this is fine... but may be you can add a comment.
> > The task can change its credentials right after ptrace_may_access()
> > succeeds. This _looks_ wrong, perhaps it makes sense to  add the
> > "we do not care" note.
> >
>
> Wait, how it's differ from other ptrace_may_access calls all over
> the kernel? I suppose I'm missing something obvious?

For example? Say, mm_access() is fine because it returns ->mm
which we are going to play with.

But map_files_d_revalidate/proc_map_files_get_link looks wrong,
there are obviously racy and should use mm_access().

Probably something else is wrong too.

Once again, I am not saying that this code really has the security
problems. I simply do not know. But it looks wrong without the
comment. I do not really understand why do we need ptrace_may_access(),
but whatever reason we have how we can trust it? Say, when KCMP_VM
checks ->mm, all we know is that PTRACE_MODE_READ succeed in the
past. This looks confusing, imho.

Oleg.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/