lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date:	Wed, 7 Mar 2012 18:41:13 +0100
From:	Oleg Nesterov <oleg@...hat.com>
To:	Cyrill Gorcunov <gorcunov@...nvz.org>
Cc:	akpm@...ux-foundation.org, linux-kernel@...r.kernel.org,
	adobriyan@...il.com, ebiederm@...ssion.com, keescook@...omium.org,
	kosaki.motohiro@...fujitsu.com, matthltc@...ibm.com, tj@...nel.org,
	xemul@...allels.com
Subject: Re: + mm-exec-rename-mm-exe_file-to-mm-exe_path.patch added to -mm
	tree

s/mm-commits/lkml/

On 03/07, Cyrill Gorcunov wrote:
>
> On Tue, Mar 06, 2012 at 03:13:25PM -0800, akpm@...ux-foundation.org wrote:
> > From: Oleg Nesterov <oleg@...hat.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@...hat.com>
> > Acked-by: Matt Helsley <matthltc@...ibm.com>
> > Cc: Alexey Dobriyan <adobriyan@...il.com>
> > Cc: Cyrill Gorcunov <gorcunov@...nvz.org>
> > Cc: "Eric W. Biederman" <ebiederm@...ssion.com>
> > Cc: Kees Cook <keescook@...omium.org>
> > Cc: KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>
> > Cc: Pavel Emelyanov <xemul@...allels.com>
> > Cc: Tejun Heo <tj@...nel.org
> > Signed-off-by: Andrew Morton <akpm@...ux-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.

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ