Re: + mm-exec-rename-mm-exe_file-to-mm-exe_path.patch added to -mm tree

Re: + mm-exec-rename-mm-exe_file-to-mm-exe_path.patch added to -mm tree

[Oleg Nesterov]

s/mm-commits/lkml/

On 03/07, Cyrill Gorcunov wrote:
>
> On Tue, Mar 06, 2012 at 03:13:25PM -0800, akpm@linux-foundation.org wrote:
> > From: Oleg Nesterov <oleg@redhat.com>
> > Subject: mm/exec: rename mm->exe_file to mm->exe_path
> >
> > Rename mm->exe_file to mm->exe_path.  We only need this member to get the
> > path - an additional reference to bprm->file makes no sense.
> >
> > The patch doesn't rename added_exe_file_vma/removed_exe_file_vma and
> > mm->num_exe_file_vmas, and perhaps we can remove them later.
> >
> > Also remove the stale comment in include/linux/mm.h.
> >
> > Signed-off-by: Oleg Nesterov <oleg@redhat.com>
> > Acked-by: Matt Helsley <matthltc@us.ibm.com>
> > Cc: Alexey Dobriyan <adobriyan@gmail.com>
> > Cc: Cyrill Gorcunov <gorcunov@openvz.org>
> > Cc: "Eric W. Biederman" <ebiederm@xmission.com>
> > Cc: Kees Cook <keescook@chromium.org>
> > Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
> > Cc: Pavel Emelyanov <xemul@parallels.com>
> > Cc: Tejun Heo <tj@kernel.org
> > Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
>
> Hi Oleg, I fear this won't work.

Why?

> The reference to the plain
> path pointer is not enough.

Why? ;)

> Previously we always have a
> copy reference to 'struct file' in mm:exe_file.

And?

> But now we don't have it and as result I can easily trigger
> NULL dereference simply reading /proc/pid/exe link in
> a cycle in one process and kill the program in another.

Thanks!

But so far I disagree, I can't understand why struct path can't work.

Of course I can be wrong, but currently I think that either this patch
reveals another problem (unlikley), or (most likely) I did some stupid
mistake.

Can you send me the reproducer just in case?

> [ 1961.066410] Code: 41 5c 41 5d c9 c3 55 48 89 e5 41 54 53 48 83 ec 30
> 66 66 66 66 90 48 63 c2 89 55 cc 48 89 fb 48 8d 04 06 48 89 45 e8 48 8b
> 7f 08 <48> 8b 87 a8 00 00 00 48 85 c0 74 0d 48 8b 40 38 48 85 c0 74 04

No sure I understand this asm... Looks like path->dentry is NULL, strange.

I do not think I really need it, but just in case... could you send me
(privately) the result of "make fs/dcache.s" ?

I'll try to recheck the patch and think.

But if you can _explain_ why do you think that "struct path" can't work,
please explain ;)

Oleg.

Re: + mm-exec-rename-mm-exe_file-to-mm-exe_path.patch added to -mm tree

[Cyrill Gorcunov]

On Wed, Mar 07, 2012 at 06:41:13PM +0100, Oleg Nesterov wrote:
...
> 
> Of course I can be wrong, but currently I think that either this patch
> reveals another problem (unlikley), or (most likely) I did some stupid
> mistake.
> 
> Can you send me the reproducer just in case?
> 
> > [ 1961.066410] Code: 41 5c 41 5d c9 c3 55 48 89 e5 41 54 53 48 83 ec 30
> > 66 66 66 66 90 48 63 c2 89 55 cc 48 89 fb 48 8d 04 06 48 89 45 e8 48 8b
> > 7f 08 <48> 8b 87 a8 00 00 00 48 85 c0 74 0d 48 8b 40 38 48 85 c0 74 04
> 
> No sure I understand this asm... Looks like path->dentry is NULL, strange.
> 
> I do not think I really need it, but just in case... could you send me
> (privately) the result of "make fs/dcache.s" ?
> 

yes, just sent.

> I'll try to recheck the patch and think.
> 
> But if you can _explain_ why do you think that "struct path" can't work,
> please explain ;)

OK, the best way to prove myself that I was wrong is to try to
explain why it can't work. So I prepared a call trace to point
where we can get a reference to non-existing path and... found
that it's simply impossible. So then I tried to repeat oops
after the test machine got rebooted and found that I can't
repeat it. I'll continue testing but I think it was unrelated
OOPs. Sorry for false alarm, Oleg!

	Cyrill

Re: + mm-exec-rename-mm-exe_file-to-mm-exe_path.patch added to -mm tree

[Oleg Nesterov]

Andrew, please drop this (trivial as I thought) patch :/

On 03/07, Cyrill Gorcunov wrote:
>
> On Wed, Mar 07, 2012 at 06:41:13PM +0100, Oleg Nesterov wrote:
> ...
> > I do not think I really need it, but just in case... could you send me
> > (privately) the result of "make fs/dcache.s" ?
> >
>
> yes, just sent.
>
> > I'll try to recheck the patch and think.
> >
> > But if you can _explain_ why do you think that "struct path" can't work,
> > please explain ;)
>
> OK, the best way to prove myself that I was wrong is to try to
> explain why it can't work. So I prepared a call trace to point
> where we can get a reference to non-existing path and... found
> that it's simply impossible.

It is possible, and you even explained this in the private email
with asm you sent me.

> OOPs. Sorry for false alarm, Oleg!

No, thanks for the report and analysis.

Indeed, the patch is deadly wrong. Somehow I missed that ->f_path
is not the pointer! So set_mm_exe_path(&bprm->file->f_path) is
is obvioulsy wrong. I didn't bother to think about "&" think call
needs.

Thanks!

Oleg.

Re: + mm-exec-rename-mm-exe_file-to-mm-exe_path.patch added to -mm tree

[Cyrill Gorcunov]

On Wed, Mar 07, 2012 at 08:51:04PM +0100, Oleg Nesterov wrote:
...
> 
> > OOPs. Sorry for false alarm, Oleg!
> 
> No, thanks for the report and analysis.
> 
> Indeed, the patch is deadly wrong. Somehow I missed that ->f_path
> is not the pointer! So set_mm_exe_path(&bprm->file->f_path) is
> is obvioulsy wrong. I didn't bother to think about "&" think call
> needs.
> 

OK. So it is not a false alarm as I thought after
trying to write a call trace, good to know ;)

Anyway, this problem is hard to repeat and I have
no idea how I managed to hit it in first place.
It was indeed "easily" until I rebooted the test
machine.

	Cyrill