linux-ext4 - Re: [PATCH] ext4: fix race conditions in ->d_compare() and ->d

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>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20200124050423.GA31271@hsiangkao-HP-ZHAN-66-Pro-G1>
Date:   Fri, 24 Jan 2020 13:04:25 +0800
From:   Gao Xiang <hsiangkao@....com>
To:     Eric Biggers <ebiggers@...nel.org>
Cc:     linux-ext4@...r.kernel.org, linux-fsdevel@...r.kernel.org,
        linux-f2fs-devel@...ts.sourceforge.net,
        Alexander Viro <viro@...iv.linux.org.uk>,
        Daniel Rosenberg <drosen@...gle.com>,
        Gabriel Krisman Bertazi <krisman@...labora.com>
Subject: Re: [PATCH] ext4: fix race conditions in ->d_compare() and ->d_hash()

Hi Eric,

On Thu, Jan 23, 2020 at 08:12:34PM -0800, Eric Biggers wrote:
> From: Eric Biggers <ebiggers@...gle.com>
> 
> Since ->d_compare() and ->d_hash() can be called in RCU-walk mode,
> ->d_parent and ->d_inode can be concurrently modified, and in
> particular, ->d_inode may be changed to NULL.  For ext4_d_hash() this
> resulted in a reproducible NULL dereference if a lookup is done in a
> directory being deleted, e.g. with:
> 
> 	int main()
> 	{
> 		if (fork()) {
> 			for (;;) {
> 				mkdir("subdir", 0700);
> 				rmdir("subdir");
> 			}
> 		} else {
> 			for (;;)
> 				access("subdir/file", 0);
> 		}
> 	}
> 
> ... or by running the 't_encrypted_d_revalidate' program from xfstests.
> Both repros work in any directory on a filesystem with the encoding
> feature, even if the directory doesn't actually have the casefold flag.
> 
> I couldn't reproduce a crash in ext4_d_compare(), but it appears that a
> similar crash is possible there.
> 
> Fix these bugs by reading ->d_parent and ->d_inode using READ_ONCE() and
> falling back to the case sensitive behavior if the inode is NULL.
> 
> Reported-by: Al Viro <viro@...iv.linux.org.uk>
> Fixes: b886ee3e778e ("ext4: Support case-insensitive file name lookups")
> Cc: <stable@...r.kernel.org> # v5.2+
> Signed-off-by: Eric Biggers <ebiggers@...gle.com>
> ---
>  fs/ext4/dir.c | 9 ++++++---
>  1 file changed, 6 insertions(+), 3 deletions(-)
> 
> diff --git a/fs/ext4/dir.c b/fs/ext4/dir.c
> index 8964778aabefb..0129d14629881 100644
> --- a/fs/ext4/dir.c
> +++ b/fs/ext4/dir.c
> @@ -671,9 +671,11 @@ static int ext4_d_compare(const struct dentry *dentry, unsigned int len,
>  			  const char *str, const struct qstr *name)
>  {
>  	struct qstr qstr = {.name = str, .len = len };
> -	struct inode *inode = dentry->d_parent->d_inode;
> +	const struct dentry *parent = READ_ONCE(dentry->d_parent);

I'm not sure if we really need READ_ONCE d_parent here (p.s. d_parent
won't be NULL anyway), and d_seq will guard all its validity. If I'm
wrong, correct me kindly...

Otherwise, it looks good to me...
Reviewed-by: Gao Xiang <gaoxiang25@...wei.com>

Thanks,
Gao Xiang


> +	const struct inode *inode = READ_ONCE(parent->d_inode);
>  
> -	if (!IS_CASEFOLDED(inode) || !EXT4_SB(inode->i_sb)->s_encoding) {
> +	if (!inode || !IS_CASEFOLDED(inode) ||
> +	    !EXT4_SB(inode->i_sb)->s_encoding) {
>  		if (len != name->len)
>  			return -1;
>  		return memcmp(str, name->name, len);
> @@ -686,10 +688,11 @@ static int ext4_d_hash(const struct dentry *dentry, struct qstr *str)
>  {
>  	const struct ext4_sb_info *sbi = EXT4_SB(dentry->d_sb);
>  	const struct unicode_map *um = sbi->s_encoding;
> +	const struct inode *inode = READ_ONCE(dentry->d_inode);
>  	unsigned char *norm;
>  	int len, ret = 0;
>  
> -	if (!IS_CASEFOLDED(dentry->d_inode) || !um)
> +	if (!inode || !IS_CASEFOLDED(inode) || !um)
>  		return 0;
>  
>  	norm = kmalloc(PATH_MAX, GFP_ATOMIC);
> -- 
> 2.25.0
>