linux-kernel - Re: [PATCH] ncpfs: fix rmdir returns Device or resource busy

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 for Android: free password hash cracker in your pocket

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

Message-ID: <1372208742.4006.31.camel@deadeye.wl.decadent.org.uk>
Date:	Wed, 26 Jun 2013 02:05:42 +0100
From:	Ben Hutchings <ben@...adent.org.uk>
To:	Luis Henriques <luis.henriques@...onical.com>
Cc:	Dave Chiluk <chiluk@...onical.com>, viro@...iv.linux.org.uk,
	petr@...drovec.name, linux-kernel@...r.kernel.org,
	stable <stable@...r.kernel.org>
Subject: Re: [PATCH] ncpfs: fix rmdir returns Device or resource busy

On Wed, 2013-06-19 at 10:30 +0100, Luis Henriques wrote:
> Dave Chiluk <chiluk@...onical.com> writes:
> 
> > 1d2ef5901483004d74947bbf78d5146c24038fe7 caused a regression in ncpfs such that
> > directories could no longer be removed.  This was because ncp_rmdir checked
> > to see if a dentry could be unhashed before allowing it to be removed. Since
> > 1d2ef5901483004d74947bbf78d5146c24038fe7 introduced a change that incremented
> > dentry->d_count causing it to always be greater than 1 unhash would always
> > fail.  Thus causing the error path in ncp_rmdir to always be taken.  Removing
> > this error path is safe as unhashing is still accomplished by calls to dput
> > from vfs_rmdir.
> 
> Stable kernels starting with 3.0 also contain the offending commit, so
> I believe this patch should be applied to stable kernels as well.
> 
> Upstream commit is 698b8223631472bf982ed570b0812faa61955683.

Queued up for 3.2, thanks.

Ben.

-- 
Ben Hutchings
Knowledge is power.  France is bacon.

Download attachment "signature.asc" of type "application/pgp-signature" (829 bytes)