lkml.org 
[lkml]   [2009]   [Aug]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    Patch in this message
    /
    Date
    From
    Subject[patch 55/74] execve: must clear current->clear_child_tid
    2.6.30-stable review patch.  If anyone has any objections, please let us know.

    ------------------

    From: Eric Dumazet <eric.dumazet@gmail.com>

    commit 9c8a8228d0827e0d91d28527209988f672f97d28 upstream.

    While looking at Jens Rosenboom bug report
    (http://lkml.org/lkml/2009/7/27/35) about strange sys_futex call done from
    a dying "ps" program, we found following problem.

    clone() syscall has special support for TID of created threads. This
    support includes two features.

    One (CLONE_CHILD_SETTID) is to set an integer into user memory with the
    TID value.

    One (CLONE_CHILD_CLEARTID) is to clear this same integer once the created
    thread dies.

    The integer location is a user provided pointer, provided at clone()
    time.

    kernel keeps this pointer value into current->clear_child_tid.

    At execve() time, we should make sure kernel doesnt keep this user
    provided pointer, as full user memory is replaced by a new one.

    As glibc fork() actually uses clone() syscall with CLONE_CHILD_SETTID and
    CLONE_CHILD_CLEARTID set, chances are high that we might corrupt user
    memory in forked processes.

    Following sequence could happen:

    1) bash (or any program) starts a new process, by a fork() call that
    glibc maps to a clone( ... CLONE_CHILD_SETTID | CLONE_CHILD_CLEARTID
    ...) syscall

    2) When new process starts, its current->clear_child_tid is set to a
    location that has a meaning only in bash (or initial program) context
    (&THREAD_SELF->tid)

    3) This new process does the execve() syscall to start a new program.
    current->clear_child_tid is left unchanged (a non NULL value)

    4) If this new program creates some threads, and initial thread exits,
    kernel will attempt to clear the integer pointed by
    current->clear_child_tid from mm_release() :

    if (tsk->clear_child_tid
    && !(tsk->flags & PF_SIGNALED)
    && atomic_read(&mm->mm_users) > 1) {
    u32 __user * tidptr = tsk->clear_child_tid;
    tsk->clear_child_tid = NULL;

    /*
    * We don't check the error code - if userspace has
    * not set up a proper pointer then tough luck.
    */
    << here >> put_user(0, tidptr);
    sys_futex(tidptr, FUTEX_WAKE, 1, NULL, NULL, 0);
    }

    5) OR : if new program is not multi-threaded, but spied by /proc/pid
    users (ps command for example), mm_users > 1, and the exiting program
    could corrupt 4 bytes in a persistent memory area (shm or memory mapped
    file)

    If current->clear_child_tid points to a writeable portion of memory of the
    new program, kernel happily and silently corrupts 4 bytes of memory, with
    unexpected effects.

    Fix is straightforward and should not break any sane program.

    Reported-by: Jens Rosenboom <jens@mcbone.net>
    Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
    Signed-off-by: Oleg Nesterov <oleg@redhat.com>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Sonny Rao <sonnyrao@us.ibm.com>
    Cc: Ingo Molnar <mingo@elte.hu>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: Ulrich Drepper <drepper@redhat.com>
    Cc: Oleg Nesterov <oleg@redhat.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

    ---
    kernel/fork.c | 22 +++++++++++-----------
    1 file changed, 11 insertions(+), 11 deletions(-)

    --- a/kernel/fork.c
    +++ b/kernel/fork.c
    @@ -568,18 +568,18 @@ void mm_release(struct task_struct *tsk,
    * the value intact in a core dump, and to save the unnecessary
    * trouble otherwise. Userland only wants this done for a sys_exit.
    */
    - if (tsk->clear_child_tid
    - && !(tsk->flags & PF_SIGNALED)
    - && atomic_read(&mm->mm_users) > 1) {
    - u32 __user * tidptr = tsk->clear_child_tid;
    + if (tsk->clear_child_tid) {
    + if (!(tsk->flags & PF_SIGNALED) &&
    + atomic_read(&mm->mm_users) > 1) {
    + /*
    + * We don't check the error code - if userspace has
    + * not set up a proper pointer then tough luck.
    + */
    + put_user(0, tsk->clear_child_tid);
    + sys_futex(tsk->clear_child_tid, FUTEX_WAKE,
    + 1, NULL, NULL, 0);
    + }
    tsk->clear_child_tid = NULL;
    -
    - /*
    - * We don't check the error code - if userspace has
    - * not set up a proper pointer then tough luck.
    - */
    - put_user(0, tidptr);
    - sys_futex(tidptr, FUTEX_WAKE, 1, NULL, NULL, 0);
    }
    }




    \
     
     \ /
      Last update: 2009-08-13 22:27    [W:4.414 / U:0.096 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site