linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Fengguang Wu <fengguang.wu@intel.com>
To: Kees Cook <keescook@chromium.org>
Cc: LKML <linux-kernel@vger.kernel.org>, Oleg Nesterov <oleg@redhat.com>
Subject: Re: yama_ptrace_access_check(): possible recursive locking detected
Date: Fri, 10 Aug 2012 09:52:22 +0800	[thread overview]
Message-ID: <20120810015222.GA19286@localhost> (raw)
In-Reply-To: <CAGXu5j+xjud3w4cYXADM-KvFPvnkaKp49j5x-wdZ66wUJjkX0g@mail.gmail.com>

On Thu, Aug 09, 2012 at 06:39:34PM -0700, Kees Cook wrote:
> Hi,
> 
> So, after taking a closer look at this, I cannot understand how it's
> possible. Yama's task_lock call is against "current", not "child",
> which is what ptrace_may_access() is locking. And the same code makes
> sure that current != child. Yama would never get called if current ==
> child.
> 
> How did you reproduce this situation?

This warning can be triggered with Dave Jones' trinity tool:

git://git.codemonkey.org.uk/trinity

That's a very dangerous tool, please only run it as normal user in a
backed up and chrooted test box. I personally run it inside an initrd.
If you are interested in reproducing this, I can send you the ready
made initrd in private email.

Thanks,
Fengguang
 
> On Thu, Jul 26, 2012 at 6:47 AM, Fengguang Wu <fengguang.wu@intel.com> wrote:
> > Hi Kees,
> >
> > Here is a recursive lock possibility:
> >
> >         ptrace_may_access()
> > =>        task_lock(task);
> >             yama_ptrace_access_check()
> >               get_task_comm()
> > =>              task_lock(task);
> >
> > [   60.230444] =============================================
> > [   60.232078] [ INFO: possible recursive locking detected ]
> > [   60.232078] 3.5.0+ #281 Not tainted
> > [   60.232078] ---------------------------------------------
> > [   60.232078] trinity-child0/17019 is trying to acquire lock:
> > [   60.232078]  (&(&p->alloc_lock)->rlock){+.+...}, at: [<c1176ffa>] get_task_comm+0x4a/0xf0
> > [   60.232078]
> > [   60.232078] but task is already holding lock:
> > [   60.232078]  (&(&p->alloc_lock)->rlock){+.+...}, at: [<c10653fa>] ptrace_may_access+0x4a/0xf0
> > [   60.232078]
> > [   60.232078] other info that might help us debug this:
> > [   60.232078]  Possible unsafe locking scenario:
> > [   60.232078]
> > [   60.232078]        CPU0
> > [   60.232078]        ----
> > [   60.232078]   lock(&(&p->alloc_lock)->rlock);
> > [   60.232078]   lock(&(&p->alloc_lock)->rlock);
> > [   60.232078]
> > [   60.232078]  *** DEADLOCK ***
> > [   60.232078]
> > [   60.232078]  May be due to missing lock nesting notation
> > [   60.232078]
> > [   60.232078] 3 locks held by trinity-child0/17019:
> > [   60.232078]  #0:  (&p->lock){+.+.+.}, at: [<c11a9683>] seq_read+0x33/0x6b0
> > [   60.232078]  #1:  (&sig->cred_guard_mutex){+.+.+.}, at: [<c11ff8ae>] lock_trace+0x2e/0xb0
> > [   60.232078]  #2:  (&(&p->alloc_lock)->rlock){+.+...}, at: [<c10653fa>] ptrace_may_access+0x4a/0xf0
> > [   60.232078]
> > [   60.232078] stack backtrace:
> > [   60.232078] Pid: 17019, comm: trinity-child0 Not tainted 3.5.0+ #281
> > [   60.232078] Call Trace:
> > [   60.232078]  [<c10c6238>] __lock_acquire+0x1498/0x14f0
> > [   60.232078]  [<c10be7e7>] ? trace_hardirqs_off+0x27/0x40
> > [   60.232078]  [<c10c6360>] lock_acquire+0xd0/0x110
> > [   60.232078]  [<c1176ffa>] ? get_task_comm+0x4a/0xf0
> > [   60.232078]  [<c1422290>] _raw_spin_lock+0x60/0x110
> > [   60.232078]  [<c1176ffa>] ? get_task_comm+0x4a/0xf0
> > [   60.232078]  [<c1176ffa>] get_task_comm+0x4a/0xf0
> > [   60.232078]  [<c1246798>] yama_ptrace_access_check+0x468/0x4a0
> > [   60.232078]  [<c124648f>] ? yama_ptrace_access_check+0x15f/0x4a0
> > [   60.232078]  [<c124209a>] security_ptrace_access_check+0x1a/0x30
> > [   60.232078]  [<c1065229>] __ptrace_may_access+0x189/0x310
> > [   60.232078]  [<c10650cc>] ? __ptrace_may_access+0x2c/0x310
> > [   60.232078]  [<c106542d>] ptrace_may_access+0x7d/0xf0
> > [   60.232078]  [<c11ff8ea>] lock_trace+0x6a/0xb0
> > [   60.232078]  [<c11ffa46>] proc_pid_stack+0x76/0x170
> > [   60.232078]  [<c1201064>] proc_single_show+0x74/0x100
> > [   60.232078]  [<c11a97b3>] seq_read+0x163/0x6b0
> > [   60.232078]  [<c105bf70>] ? do_setitimer+0x220/0x330
> > [   60.232078]  [<c11a9650>] ? seq_lseek+0x1f0/0x1f0
> > [   60.232078]  [<c116b55a>] vfs_read+0xca/0x280
> > [   60.232078]  [<c11a9650>] ? seq_lseek+0x1f0/0x1f0
> > [   60.232078]  [<c116b776>] sys_read+0x66/0xe0
> > [   60.232078]  [<c1423d9d>] syscall_call+0x7/0xb
> > [   60.232078]  [<c1420000>] ? __schedule+0x2a0/0xc80
> >
> > Thanks,
> > Fengguang
> 
> 
> 
> -- 
> Kees Cook
> Chrome OS Security

  reply	other threads:[~2012-08-10  1:52 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-07-26 13:47 yama_ptrace_access_check(): possible recursive locking detected Fengguang Wu
2012-07-26 15:41 ` Oleg Nesterov
2012-07-30 17:00   ` Kees Cook
2012-08-10  1:39 ` Kees Cook
2012-08-10  1:52   ` Fengguang Wu [this message]
2012-08-14 21:16     ` Kees Cook
2012-08-15  3:01       ` Fengguang Wu
2012-08-15  5:56         ` Kees Cook
2012-08-15  8:05           ` Peter Zijlstra
2012-08-15 13:01           ` Oleg Nesterov
2012-08-15 14:30             ` Peter Zijlstra
2012-08-15 17:56               ` Oleg Nesterov
2012-08-15 18:09                 ` Kees Cook
2012-08-15 18:17                   ` Oleg Nesterov
2012-08-15 18:30                     ` Kees Cook
2012-08-15 18:44                   ` Alan Cox
2012-08-15 18:43                     ` Kees Cook

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20120810015222.GA19286@localhost \
    --to=fengguang.wu@intel.com \
    --cc=keescook@chromium.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=oleg@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).