ecryptfs: dont call lookup_one_len to avoid NULL nameidata
authorLino Sanfilippo <linosanfilippo@gmx.de>
Thu, 15 Jul 2010 13:11:55 +0000 (15:11 +0200)
committerTyler Hicks <tyhicks@linux.vnet.ibm.com>
Mon, 9 Aug 2010 18:42:12 +0000 (13:42 -0500)
commit21edad32205e97dc7ccb81a85234c77e760364c8
treed68f20aa288a6fe98547fe348d3c300020ad8daf
parentceeab92971e8af05c1e81a4ff2c271124b55bb9b
ecryptfs: dont call lookup_one_len to avoid NULL nameidata

I have encountered the same problem that Eric Sandeen described in
this post

 http://lkml.org/lkml/fancy/2010/4/23/467

while experimenting with stackable filesystems.

The reason seems to be that ecryptfs calls lookup_one_len() to get the
lower dentry, which in turn calls the lower parent dirs d_revalidate()
with a NULL nameidata object.
If ecryptfs is the underlaying filesystem, the NULL pointer dereference
occurs, since ecryptfs is not prepared to handle a NULL nameidata.

I know that this cant happen any more, since it is no longer allowed to
mount ecryptfs upon itself.

But maybe this patch it useful nevertheless, since the problem would still
apply for an underlaying filesystem that implements d_revalidate() and is
not prepared to handle a NULL nameidata (I dont know if there actually
is such a fs).

With this patch (against 2.6.35-rc5) ecryptfs uses the vfs_lookup_path()
function instead of lookup_one_len() which ensures that the nameidata
passed to the lower filesystems d_revalidate().

Signed-off-by: Lino Sanfilippo <LinoSanfilippo@gmx.de>
Signed-off-by: Tyler Hicks <tyhicks@linux.vnet.ibm.com>
fs/ecryptfs/inode.c