On Tue, 21 Jun 2005 23:51:44 -0700
Andrew Morton <[email protected]> wrote:
> Someone does a call_usermodehelper() which uses CLONE_VFORK. The new
> process at `p' exits quickly so when the parent returns from
> wait_for_completion() it is left with freed memory at *p. When the parent
> tries to reference p->pid we oops due to the use-after-free bug.
>
> Guillaume, I'll do this for now:
>
> --- 25/kernel/fork.c~connector-add-a-fork-connector-use-after-free-fix 2005-06-21 23:46:35.000000000 -0700
> +++ 25-akpm/kernel/fork.c 2005-06-21 23:46:58.000000000 -0700
> @@ -1248,14 +1248,15 @@ long do_fork(unsigned long clone_flags,
> ptrace_notify ((trace << 8) | SIGTRAP);
> }
>
> + fork_connector(current->tgid, current->pid, p->tgid, p->pid);
> +
> if (clone_flags & CLONE_VFORK) {
> +
> wait_for_completion(&vfork);
> if (unlikely (current->ptrace & PT_TRACE_VFORK_DONE))
> - ptrace_notify ((PTRACE_EVENT_VFORK_DONE << 8) | SIGTRAP);
> + ptrace_notify((PTRACE_EVENT_VFORK_DONE << 8) |
> + SIGTRAP);
> }
> -
> - fork_connector(current->tgid, current->pid,
> - p->tgid, p->pid);
> } else {
> free_pidmap(pid);
> pid = PTR_ERR(p);
> _
>
>
> But you need to work out what semantics you want for vfork()?
The information about the creation of a new process is sent through the
connector and it's available to every application that is connected to
the fork connector even if this new process is an "helper" program or
has the CLONE_VFORK flag set. The problem with "helper" program is that
we can not know if it is terminated but it's the problem of the
application that uses this kind of information.
So I think the fix is correct and the application that uses the fork
connector will take the decision if the sending information is
interesting or not. To help the application in this choice it could be
interesting to add the 'clone_flags' in the fork_connector() parameters.
By doing this we could know if two processes run in the same memory
space or share other ressources. I'm working on this.
Thank you for your help,
Guillaume
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
