linux-kernel - [PATCH] ecryptfs: dont call lookup_one

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <4C3F091B.2020108@gmx.de>
Date:	Thu, 15 Jul 2010 15:11:55 +0200
From:	Lino Sanfilippo <linosanfilippo@....de>
To:	sandeen@...hat.com
CC:	linux-kernel@...r.kernel.org, tyhicks@...ux.vnet.ibm.com,
	kirkland@...onical.com, viro@...iv.linux.org.uk,
	ecryptfs-devel@...ts.launchpad.net
Subject: [PATCH] ecryptfs: dont call lookup_one_len to avoid NULL nameidata

Hi,

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().

Lino Sanfilippo

Signed-off-by: Lino Sanfilippo <LinoSanfilippo@....de>

View attachment "patch" of type "text/plain" (3610 bytes)