Re: [PATCH] kernel/kmod: fix use-after-free of the sub_info structure

2014-10-17 Thread Tetsuo Handa
Martin Schwidefsky wrote: > Oleg Nesterov wrote: > > I also agree that the changelog could mention exec_mmap. Plus a comment > > about UMH_NO_WAIT && sub_info->complete == NULL. So yes, perhaps v2 makes > > sense if Martin agrees. > > Version 2 of the patch. All change requests have gone in excep

Re: [PATCH] kernel/kmod: fix use-after-free of the sub_info structure

2014-10-16 Thread Oleg Nesterov
On 10/16, Oleg Nesterov wrote: > > OK... I am wondering if __call_usermodehelper() still needs CLONE_VFORK > with this patch. Yes, looks like it doesn't, but this needs another patch. > > @@ -588,7 +580,7 @@ int call_usermodehelper_exec(struct subprocess_info > > *sub_info, int wait) > >

Re: [PATCH] kernel/kmod: fix use-after-free of the sub_info structure

2014-10-16 Thread Oleg Nesterov
On 10/17, Tetsuo Handa wrote: > > For both UMH_NO_WAIT and UMH_WAIT_EXEC cases, > > kernel_thread(call_helper, sub_info, CLONE_VFORK | SIGCHLD) > > in __call_usermodehelper() waits for do_execve() to succeed or do_exit(), Well, not really. kernel_thread(CLONE_VFORK) waits for do_exit() or exec_m

Re: [PATCH] kernel/kmod: fix use-after-free of the sub_info structure

2014-10-16 Thread Oleg Nesterov
On 10/16, Martin Schwidefsky wrote: > > There is a use-after-free bug on the subprocess_info structure allocated > by the user mode helper. In case do_execve() returns with an error > call_usermodehelper() stores the error code to sub_info->retval, > but sub_info can already have been freed. H

Re: [PATCH] kernel/kmod: fix use-after-free of the sub_info structure

2014-10-16 Thread Tetsuo Handa
Martin Schwidefsky wrote: > Found this in the message log on a s390 system: > > BUG kmalloc-192 (Not tainted): Poison overwritten The use-after-free location you are suspecting is -- retval = do_execve(getname_kernel(sub_info->path), (const char __user

[PATCH] kernel/kmod: fix use-after-free of the sub_info structure

2014-10-16 Thread Martin Schwidefsky
Found this in the message log on a s390 system: BUG kmalloc-192 (Not tainted): Poison overwritten Disabling lock debugging due to kernel taint INFO: 0x684761f4-0x684761f7. First byte 0xff instead of 0x6b INFO: Allocated in call_usermodehelper_setup+0x70/0x128 age=71 cpu=2 pid=648