From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932456Ab2HJBw1 (ORCPT ); Thu, 9 Aug 2012 21:52:27 -0400 Received: from mga11.intel.com ([192.55.52.93]:8637 "EHLO mga11.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932264Ab2HJBwZ (ORCPT ); Thu, 9 Aug 2012 21:52:25 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.77,743,1336374000"; d="scan'208";a="195926862" Date: Fri, 10 Aug 2012 09:52:22 +0800 From: Fengguang Wu To: Kees Cook Cc: LKML , Oleg Nesterov Subject: Re: yama_ptrace_access_check(): possible recursive locking detected Message-ID: <20120810015222.GA19286@localhost> References: <20120726134748.GA20605@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 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: [] get_task_comm+0x4a/0xf0 > > [ 60.232078] > > [ 60.232078] but task is already holding lock: > > [ 60.232078] (&(&p->alloc_lock)->rlock){+.+...}, at: [] 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: [] seq_read+0x33/0x6b0 > > [ 60.232078] #1: (&sig->cred_guard_mutex){+.+.+.}, at: [] lock_trace+0x2e/0xb0 > > [ 60.232078] #2: (&(&p->alloc_lock)->rlock){+.+...}, at: [] 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] [] __lock_acquire+0x1498/0x14f0 > > [ 60.232078] [] ? trace_hardirqs_off+0x27/0x40 > > [ 60.232078] [] lock_acquire+0xd0/0x110 > > [ 60.232078] [] ? get_task_comm+0x4a/0xf0 > > [ 60.232078] [] _raw_spin_lock+0x60/0x110 > > [ 60.232078] [] ? get_task_comm+0x4a/0xf0 > > [ 60.232078] [] get_task_comm+0x4a/0xf0 > > [ 60.232078] [] yama_ptrace_access_check+0x468/0x4a0 > > [ 60.232078] [] ? yama_ptrace_access_check+0x15f/0x4a0 > > [ 60.232078] [] security_ptrace_access_check+0x1a/0x30 > > [ 60.232078] [] __ptrace_may_access+0x189/0x310 > > [ 60.232078] [] ? __ptrace_may_access+0x2c/0x310 > > [ 60.232078] [] ptrace_may_access+0x7d/0xf0 > > [ 60.232078] [] lock_trace+0x6a/0xb0 > > [ 60.232078] [] proc_pid_stack+0x76/0x170 > > [ 60.232078] [] proc_single_show+0x74/0x100 > > [ 60.232078] [] seq_read+0x163/0x6b0 > > [ 60.232078] [] ? do_setitimer+0x220/0x330 > > [ 60.232078] [] ? seq_lseek+0x1f0/0x1f0 > > [ 60.232078] [] vfs_read+0xca/0x280 > > [ 60.232078] [] ? seq_lseek+0x1f0/0x1f0 > > [ 60.232078] [] sys_read+0x66/0xe0 > > [ 60.232078] [] syscall_call+0x7/0xb > > [ 60.232078] [] ? __schedule+0x2a0/0xc80 > > > > Thanks, > > Fengguang > > > > -- > Kees Cook > Chrome OS Security