From mboxrd@z Thu Jan 1 00:00:00 1970 From: OGAWA Hirofumi Subject: Re: [PATCH] vfs: Fix use-after-free of vfsmount by mnt_drop_write() Date: Tue, 23 Feb 2010 06:13:59 +0900 Message-ID: <87pr3x6kiw.fsf@devron.myhome.or.jp> References: <874ol9cfm7.fsf@devron.myhome.or.jp> <20100222205429.GH972@shell> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Al Viro , linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org To: Valerie Aurora Return-path: In-Reply-To: <20100222205429.GH972@shell> (Valerie Aurora's message of "Mon, 22 Feb 2010 15:54:29 -0500") Sender: linux-kernel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org Valerie Aurora writes: >> Those might be assuming that the nd->path.mnt refcnt is keeped by >> filp after nameidata_to_filp(). >> >> It's wrong if nameidata_to_filp() returned the error. (nd->path and >> filp are invalid) >> >> Instead to use deep knowledge of nameidata_to_filp() internal, this >> thinks the nd->path is invalid after nameidata_to_filp(). So, this >> just take refcnt for mnt_want/drop_write(). > > You might take a look at the patch I just posted: > > Subject: [RFC PATCH] VFS: Simplify truncate logic in do_filp_open() > > If that patch is correct, it will considerably simplify the second > part of your patch. [...] >> /* >> - * It is now safe to drop the mnt write >> - * because the filp has had a write taken >> - * on its behalf. >> + * It is now safe to drop the mnt write because the filp has >> + * had a write taken on its behalf. (NOTE: since O_TRUNC can >> + * be used with O_RDONLY, this needs to cover truncate path) >> */ >> - if (will_truncate) >> - mnt_drop_write(nd.path.mnt); >> + if (will_truncate) { >> + mnt_drop_write(mnt_writer); >> + mntput(mnt_writer); >> + } Unfortunately, no. I already noted that we can't it simply. ;) Thanks. -- OGAWA Hirofumi