linux-ext4 - Re: [PATCH 5/6] f2fs: switch to using fscrypt_match

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: <20170425174632.GA41477@gmail.com>
Date:   Tue, 25 Apr 2017 10:46:32 -0700
From:   Eric Biggers <ebiggers3@...il.com>
To:     Richard Weinberger <richard.weinberger@...il.com>
Cc:     linux-fscrypt@...r.kernel.org,
        Ryo Hashimoto <hashimoto@...omium.org>,
        Gwendal Grignou <gwendal@...omium.org>,
        "Theodore Y . Ts'o" <tytso@....edu>,
        Eric Biggers <ebiggers@...gle.com>,
        linux-f2fs-devel@...ts.sourceforge.net,
        "linux-mtd@...ts.infradead.org" <linux-mtd@...ts.infradead.org>,
        Jaegeuk Kim <jaegeuk@...nel.org>, linux-ext4@...r.kernel.org,
        Kazuhiro Inaba <kinaba@...omium.org>,
        David Gstir <david@...ma-star.at>
Subject: Re: [PATCH 5/6] f2fs: switch to using fscrypt_match_name()

Hi Richard,

On Tue, Apr 25, 2017 at 03:37:56PM +0200, Richard Weinberger wrote:
> Eric, Jaegeuk,
> 
> 
> On Mon, Apr 24, 2017 at 7:00 PM, Eric Biggers <ebiggers3@...il.com> wrote:
> > From: Eric Biggers <ebiggers@...gle.com>
> >
> > Switch f2fs directory searches to use the fscrypt_match_name() helper
> > function.  There should be no functional change.
> 
> > -#ifdef CONFIG_F2FS_FS_ENCRYPTION
> > -               if (unlikely(!name->name)) {
> > -                       if (fname->usr_fname->name[0] == '_') {
> > -                               if (de_name.len > 32 &&
> > -                                       !memcmp(de_name.name + ((de_name.len - 17) & ~15),
> > -                                               fname->crypto_buf.name + 8, 16))
> > -                                       goto found;
> > -                               goto not_match;
> > -                       }
> > -                       name->name = fname->crypto_buf.name;
> > -                       name->len = fname->crypto_buf.len;
> > -               }
> 
> Sorry if this is a stupid question, but why do you have to compare hashes _and_
> the last few bytes of the bigname?
> A lookup via bigname gives you two 32bits hash values, and there I'd assume that
> this is sufficient for a collisions free lookup. Especially since an
> resumed readdir()
> with a 64bits cookie has to work too on your filesystem.
> 

Well, the problem is that hashes may not be sufficient to uniquely identify a
name in all cases.  f2fs uses only a 32-bit hash so it's trivial to create
collisions on it, as I demonstrated.  Even collisions of two 32-bit hashes, as
used by ext4 and ubifs, are possible.  And ext4 currently doesn't even compare
the hashes during directory searches, beyond using them to find the correct
directory block, since the hashes aren't stored in the directory entries.

Could this mean that telldir()/seekdir() is unreliable too, probably.  But for
lookups of the "digested" names we aren't limited to just the 64-bit readdir
position, so we can avoid duplicating the bug.  Also, collisions in the digested
names are very problematic since they result in undeletable files, rather than
just poor performance and broken telldir()/seekdir().

- Eric