]> git.baikalelectronics.ru Git - kernel.git/commit
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)
commitb0aeaa5c5188ab7515fe2e996b331ccad12e11e3
treed68f20aa288a6fe98547fe348d3c300020ad8daf
parentf961514cac5f0e89c075eb572827cdaee5aa3ec8
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