From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756057AbcETQzr (ORCPT ); Fri, 20 May 2016 12:55:47 -0400 Received: from aserp1040.oracle.com ([141.146.126.69]:29773 "EHLO aserp1040.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751331AbcETQzq (ORCPT ); Fri, 20 May 2016 12:55:46 -0400 Subject: Re: [PATCH v6 2/8] debugfs: prevent access to removed files' private data To: Nicolai Stange References: <1458652280-19785-1-git-send-email-nicstange@gmail.com> <1458652280-19785-3-git-send-email-nicstange@gmail.com> <573C80C8.6090307@oracle.com> <87r3czxvea.fsf@gmail.com> <573C87B8.902@oracle.com> <87mvnnxr74.fsf@gmail.com> Cc: Greg Kroah-Hartman , Rasmus Villemoes , "Paul E. McKenney" , Alexander Viro , Jonathan Corbet , Jan Kara , Andrew Morton , Julia Lawall , Gilles Muller , Nicolas Palix , Michal Marek , linux-kernel@vger.kernel.org, cocci@systeme.lip6.fr From: Sasha Levin Message-ID: <573F4171.4080804@oracle.com> Date: Fri, 20 May 2016 12:55:13 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <87mvnnxr74.fsf@gmail.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Source-IP: aserv0021.oracle.com [141.146.126.233] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 05/18/2016 12:32 PM, Nicolai Stange wrote: > Sasha Levin writes: > >> On 05/18/2016 11:01 AM, Nicolai Stange wrote: >>> Thanks a million for reporting! >>> >>> 1.) Do you have lockdep enabled? >> >> Yup, nothing there. >> >>> 2.) Does this happen before or after userspace init has been spawned, >>> i.e. does the lockup happen at debugfs file creation time or >>> possibly at usage time? >> >> So I looked closer, and it seems to happen after starting syzkaller, which >> as far as I know tries to open many different debugfs files. >> >> Is there debug code I can add it that'll help us figure out what's up? > > Could you try the patch below? I stared at the new full_proxy_open() for > a while now and had to recognize the fact that if the original real_fops' > ->open() fails, then its owning module's reference won't ever get > dropped :( > > diff --git a/fs/debugfs/file.c b/fs/debugfs/file.c > index 6eb58a8..2e663d4 100644 > --- a/fs/debugfs/file.c > +++ b/fs/debugfs/file.c > @@ -263,10 +263,14 @@ static int full_proxy_open(struct inode *inode, struct file *filp) > if (real_fops->open) { > r = real_fops->open(inode, filp); > > - if (filp->f_op != proxy_fops) { > + if (r) { > + replace_fops(filp, d_inode(dentry)->i_fop); > + goto free_proxy; > + } else if (filp->f_op != proxy_fops) { > /* No protection against file removal anymore. */ > WARN(1, "debugfs file owner replaced proxy fops: %pd", > dentry); > + replace_fops(filp, d_inode(dentry)->i_fop); > goto free_proxy; > } > } > > > I don't see directly how this could lead to lockups, but I think it's > better to rule out the obvious before inserting more or less random > printks... > > Thank you very much again, Nope, that didn't do the trick. Thanks, Sasha