Searched hist:"21 edad32" (Results 1 – 1 of 1) sorted by relevance
| /openbmc/linux/fs/ecryptfs/ |
| H A D | inode.c | 21edad32 Thu Jul 15 08:11:55 CDT 2010 Lino Sanfilippo <linosanfilippo@gmx.de> 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>
21edad32 Thu Jul 15 08:11:55 CDT 2010 Lino Sanfilippo <linosanfilippo@gmx.de> 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>
|