linux-kernel - ptrace(PTRACE_ATTACH) [no intervering wait] ptrace(PTRACE

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 23 Jul 2013 12:05:14 +0200
From:	Mike Galbraith <bitbucket@...ine.de>
To:	LKML <linux-kernel@...r.kernel.org>
Cc:	Oleg Nesterov <oleg@...hat.com>
Subject: ptrace(PTRACE_ATTACH)  [no intervering wait] ptrace(PTRACE_DETACH)
 may leave tracee stuck

I received a report that glibc:elf/pldd hangs occasionally, and indeed..

  for i in `seq 1 1000`; do taskset -c 3 pldd $$ > /dev/null 2>&1; done

..will do so.  Rummage.....

ptrace(PTRACE_DETACH) returns -ESRCH when the trap hasn't happened yet,
which happens because pldd doesn't wait() before ptrace(PTRACE_DETACH).

pldd source:

      if (ptrace (PTRACE_ATTACH, tid, NULL, NULL) != 0)
        {
          /* There might be a race between reading the directory and
             threads terminating.  Ignore errors attaching to unknown
             threads unless this is the main thread.  */
          if (errno == ESRCH && tid != pid)
            continue;

          error (EXIT_FAILURE, errno, gettext ("cannot attach to process %lu"),
                 tid);
        } 

      struct thread_list *newp = alloca (sizeof (*newp));
      newp->tid = tid;
      newp->next = thread_list;
      thread_list = newp;
    }

  closedir (dir);

  int status = get_process_info (dfd, pid);

  assert (thread_list != NULL);
  do
    {
      ptrace (PTRACE_DETACH, thread_list->tid, NULL, NULL);
      thread_list = thread_list->next;
    }
  while (thread_list != NULL);

Seems this usually works only because cycles expended between attach and
detach is usually enough to let trap happen so tracee can set its state
to TASK_TRACED as PTRACE_DETACH expects it to be.

Is this expected behavior?  It looks a bit like "Doctor Doctor..".

-Mike

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/