[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20200125033522.GM147870@mit.edu>
Date: Fri, 24 Jan 2020 22:35:22 -0500
From: "Theodore Y. Ts'o" <tytso@....edu>
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()
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>
Thanks, applied.
- Ted
Powered by blists - more mailing lists