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
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)
> >
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
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
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
5 matches
Mail list logo