• Roland McGrath's avatar
    [PATCH] fix PTRACE_ATTACH race with real parent's wait calls · cfc4f957
    Roland McGrath authored
    There is a race between PTRACE_ATTACH and the real parent calling wait. 
    For a moment, the task is put in PT_PTRACED but with its parent still
    pointing to its real_parent.  In this circumstance, if the real parent
    calls wait without the WUNTRACED flag, he can see a stopped child status,
    which wait should never return without WUNTRACED when the caller is not
    using ptrace.  Here it is not the caller that is using ptrace, but some
    third party.
    
    This patch avoids this race condition by adding the PT_ATTACHED flag to
    distinguish a real parent from a ptrace_attach parent when PT_PTRACED is
    set, and then having wait use this flag to confirm that things are in order
    and not consider the child ptraced when its ->ptrace flags are set but its
    parent links have not yet been switched.  (ptrace_check_attach also uses it
    similarly to rule out a possible race with a bogus ptrace call by the real
    parent during ptrace_attach.)
    
    While looking into this, I noticed that every arch's sys_execve has:
    
    		current->ptrace &= ~PT_DTRACE;
    
    with no locking at all.  So, if an exec happens in a race with
    PTRACE_ATTACH, you could wind up with ->ptrace not having PT_PTRACED set
    because this store clobbered it.  That will cause later BUG hits because
    the parent links indicate ptracedness but the flag is not set.  The patch
    corrects all the places I found to use task_lock around diddling ->ptrace
    when it's possible to be racing with ptrace_attach.  (The ptrace operation
    code itself doesn't have this issue because it already excludes anyone else
    being in ptrace_attach.)
    Signed-off-by: default avatarRoland McGrath <roland@redhat.com>
    Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
    Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
    cfc4f957
fs.c 4.77 KB