fscrypt: avoid collisions when presenting long encrypted filenames

commit 6b06cdee81d68a8a829ad8e8d0f31d6836744af9 upstream.

When accessing an encrypted directory without the key, userspace must
operate on filenames derived from the ciphertext names, which contain
arbitrary bytes.  Since we must support filenames as long as NAME_MAX,
we can't always just base64-encode the ciphertext, since that may make
it too long.  Currently, this is solved by presenting long names in an
abbreviated form containing any needed filesystem-specific hashes (e.g.
to identify a directory block), then the last 16 bytes of ciphertext.
This needs to be sufficient to identify the actual name on lookup.

However, there is a bug.  It seems to have been assumed that due to the
use of a CBC (ciphertext block chaining)-based encryption mode, the last
16 bytes (i.e. the AES block size) of ciphertext would depend on the
full plaintext, preventing collisions.  However, we actually use CBC
with ciphertext stealing (CTS), which handles the last two blocks
specially, causing them to appear "flipped".  Thus, it's actually the
second-to-last block which depends on the full plaintext.

This caused long filenames that differ only near the end of their
plaintexts to, when observed without the key, point to the wrong inode
and be undeletable.  For example, with ext4:

    # echo pass | e4crypt add_key -p 16 edir/
    # seq -f "edir/abcdefghijklmnopqrstuvwxyz012345%.0f" 100000 | xargs touch
    # find edir/ -type f | xargs stat -c %i | sort | uniq | wc -l
    100000
    # sync
    # echo 3 > /proc/sys/vm/drop_caches
    # keyctl new_session
    # find edir/ -type f | xargs stat -c %i | sort | uniq | wc -l
    2004
    # rm -rf edir/
    rm: cannot remove 'edir/_A7nNFi3rhkEQlJ6P,hdzluhODKOeWx5V': Structure needs cleaning
    ...

To fix this, when presenting long encrypted filenames, encode the
second-to-last block of ciphertext rather than the last 16 bytes.

Although it would be nice to solve this without depending on a specific
encryption mode, that would mean doing a cryptographic hash like SHA-256
which would be much less efficient.  This way is sufficient for now, and
it's still compatible with encryption modes like HEH which are strong
pseudorandom permutations.  Also, changing the presented names is still
allowed at any time because they are only provided to allow applications
to do things like delete encrypted directories.  They're not designed to
be used to persistently identify files --- which would be hard to do
anyway, given that they're encrypted after all.

For ease of backports, this patch only makes the minimal fix to both
ext4 and f2fs.  It leaves ubifs as-is, since ubifs doesn't compare the
ciphertext block yet.  Follow-on patches will clean things up properly
and make the filesystems use a shared helper function.

Fixes: 5de0b4d0cd15 ("ext4 crypto: simplify and speed up filename encryption")
Reported-by: Gwendal Grignou <gwendal@chromium.org>
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

diff --git a/fs/ext4/crypto_fname.c b/fs/ext4/crypto_fname.c
index 2fbef8a14760f4095300c9fdc0edcdc2909f4a65..2cfe3ffc276ff5011fd17b3940976249faf95149 100644 (file)
--- a/fs/ext4/crypto_fname.c
+++ b/fs/ext4/crypto_fname.c
@@ -343,7 +343,7 @@ int _ext4_fname_disk_to_usr(struct inode *inode,
                memcpy(buf+4, &hinfo->minor_hash, 4);
        } else
                memset(buf, 0, 8);
-       memcpy(buf + 8, iname->name + iname->len - 16, 16);
+       memcpy(buf + 8, iname->name + ((iname->len - 17) & ~15), 16);
        oname->name[0] = '_';
        ret = digest_encode(buf, 24, oname->name+1);
        oname->len = ret + 1;

diff --git a/fs/ext4/namei.c b/fs/ext4/namei.c
index fafa903ab3c0f2a8b32816b44408225f173a08e7..1d007e853f5c19c83a00724fd0fc87eee11efff5 100644 (file)
--- a/fs/ext4/namei.c
+++ b/fs/ext4/namei.c
@@ -1243,9 +1243,9 @@ static inline int ext4_match(struct ext4_filename *fname,
        if (unlikely(!name)) {
                if (fname->usr_fname->name[0] == '_') {
                        int ret;
-                       if (de->name_len < 16)
+                       if (de->name_len <= 32)
                                return 0;
-                       ret = memcmp(de->name + de->name_len - 16,
+                       ret = memcmp(de->name + ((de->name_len - 17) & ~15),
                                     fname->crypto_buf.name + 8, 16);
                        return (ret == 0) ? 1 : 0;
                }

diff --git a/fs/f2fs/crypto_fname.c b/fs/f2fs/crypto_fname.c
index ab377d496a39ad47924a3f79b48e1aad7538f2d2..38349ed5ea51a352980d0d35067070b01308049f 100644 (file)
--- a/fs/f2fs/crypto_fname.c
+++ b/fs/f2fs/crypto_fname.c
@@ -333,7 +333,7 @@ int f2fs_fname_disk_to_usr(struct inode *inode,
                memset(buf + 4, 0, 4);
        } else
                memset(buf, 0, 8);
-       memcpy(buf + 8, iname->name + iname->len - 16, 16);
+       memcpy(buf + 8, iname->name + ((iname->len - 17) & ~15), 16);
        oname->name[0] = '_';
        ret = digest_encode(buf, 24, oname->name + 1);
        oname->len = ret + 1;

diff --git a/fs/f2fs/dir.c b/fs/f2fs/dir.c
index 45c07a88f8ba186ed001f7e47534b313c2f37ab8..60972a559685b359779fe7ea91ee0fda509b4139 100644 (file)
--- a/fs/f2fs/dir.c
+++ b/fs/f2fs/dir.c
@@ -133,8 +133,8 @@ struct f2fs_dir_entry *find_target_dentry(struct f2fs_filename *fname,
 #ifdef CONFIG_F2FS_FS_ENCRYPTION
                if (unlikely(!name->name)) {
                        if (fname->usr_fname->name[0] == '_') {
-                               if (de_name.len >= 16 &&
-                                       !memcmp(de_name.name + de_name.len - 16,
+                               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;