[PATCH] fscrypt: Replace 1-element array with flexible array

[PATCH] fscrypt: Replace 1-element array with flexible array

[Kees Cook]

1-element arrays are deprecated, and are being replaced with C99
flexible arrays[1]. In the future, we can add annotations for the
flexible array member "encrypted_path" to have a size determined
by the "len" member.

As sizes were being calculated with the extra byte intentionally,
propagate the difference so there is no change in binary output.

[1] https://github.com/KSPP/linux/issues/79

Cc: Eric Biggers <ebiggers@kernel.org>
Cc: "Theodore Y. Ts'o" <tytso@mit.edu>
Cc: Jaegeuk Kim <jaegeuk@kernel.org>
Cc: Gustavo A. R. Silva <gustavoars@kernel.org>
Cc: linux-fscrypt@vger.kernel.org
Signed-off-by: Kees Cook <keescook@chromium.org>
---
 fs/crypto/fscrypt_private.h |  2 +-
 fs/crypto/hooks.c           | 10 +++++-----
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/fs/crypto/fscrypt_private.h b/fs/crypto/fscrypt_private.h
index 7ab5a7b7eef8..2d63da48635a 100644
--- a/fs/crypto/fscrypt_private.h
+++ b/fs/crypto/fscrypt_private.h
@@ -171,7 +171,7 @@ fscrypt_policy_flags(const union fscrypt_policy *policy)
  */
 struct fscrypt_symlink_data {
 	__le16 len;
-	char encrypted_path[1];
+	char encrypted_path[];
 } __packed;
 
 /**
diff --git a/fs/crypto/hooks.c b/fs/crypto/hooks.c
index 9e786ae66a13..6238dbcadcad 100644
--- a/fs/crypto/hooks.c
+++ b/fs/crypto/hooks.c
@@ -255,10 +255,10 @@ int fscrypt_prepare_symlink(struct inode *dir, const char *target,
 	 * for now since filesystems will assume it is there and subtract it.
 	 */
 	if (!__fscrypt_fname_encrypted_size(policy, len,
-					    max_len - sizeof(struct fscrypt_symlink_data),
+					    max_len - sizeof(struct fscrypt_symlink_data) - 1,
 					    &disk_link->len))
 		return -ENAMETOOLONG;
-	disk_link->len += sizeof(struct fscrypt_symlink_data);
+	disk_link->len += sizeof(struct fscrypt_symlink_data) + 1;
 
 	disk_link->name = NULL;
 	return 0;
@@ -289,7 +289,7 @@ int __fscrypt_encrypt_symlink(struct inode *inode, const char *target,
 		if (!sd)
 			return -ENOMEM;
 	}
-	ciphertext_len = disk_link->len - sizeof(*sd);
+	ciphertext_len = disk_link->len - sizeof(*sd) - 1;
 	sd->len = cpu_to_le16(ciphertext_len);
 
 	err = fscrypt_fname_encrypt(inode, &iname, sd->encrypted_path,
@@ -367,7 +367,7 @@ const char *fscrypt_get_symlink(struct inode *inode, const void *caddr,
 	 * the ciphertext length, even though this is redundant with i_size.
 	 */
 
-	if (max_size < sizeof(*sd))
+	if (max_size < sizeof(*sd) + 1)
 		return ERR_PTR(-EUCLEAN);
 	sd = caddr;
 	cstr.name = (unsigned char *)sd->encrypted_path;
@@ -376,7 +376,7 @@ const char *fscrypt_get_symlink(struct inode *inode, const void *caddr,
 	if (cstr.len == 0)
 		return ERR_PTR(-EUCLEAN);
 
-	if (cstr.len + sizeof(*sd) - 1 > max_size)
+	if (cstr.len + sizeof(*sd) > max_size)
 		return ERR_PTR(-EUCLEAN);
 
 	err = fscrypt_fname_alloc_buffer(cstr.len, &pstr);
-- 
2.34.1

Re: [PATCH] fscrypt: Replace 1-element array with flexible array

[Bill Wendling]

On Mon, May 22, 2023 at 2:39 PM Kees Cook <keescook@chromium.org> wrote:
>
> 1-element arrays are deprecated, and are being replaced with C99
> flexible arrays[1]. In the future, we can add annotations for the
> flexible array member "encrypted_path" to have a size determined
> by the "len" member.
>
> As sizes were being calculated with the extra byte intentionally,
> propagate the difference so there is no change in binary output.
>
> [1] https://github.com/KSPP/linux/issues/79
>
> Cc: Eric Biggers <ebiggers@kernel.org>
> Cc: "Theodore Y. Ts'o" <tytso@mit.edu>
> Cc: Jaegeuk Kim <jaegeuk@kernel.org>
> Cc: Gustavo A. R. Silva <gustavoars@kernel.org>
> Cc: linux-fscrypt@vger.kernel.org
> Signed-off-by: Kees Cook <keescook@chromium.org>

Reviewed-By: Bill Wendling <morbo@google.com>

(With a tear in my eye about the original code...)

> ---
>  fs/crypto/fscrypt_private.h |  2 +-
>  fs/crypto/hooks.c           | 10 +++++-----
>  2 files changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/fs/crypto/fscrypt_private.h b/fs/crypto/fscrypt_private.h
> index 7ab5a7b7eef8..2d63da48635a 100644
> --- a/fs/crypto/fscrypt_private.h
> +++ b/fs/crypto/fscrypt_private.h
> @@ -171,7 +171,7 @@ fscrypt_policy_flags(const union fscrypt_policy *policy)
>   */
>  struct fscrypt_symlink_data {
>         __le16 len;
> -       char encrypted_path[1];
> +       char encrypted_path[];
>  } __packed;
>
>  /**
> diff --git a/fs/crypto/hooks.c b/fs/crypto/hooks.c
> index 9e786ae66a13..6238dbcadcad 100644
> --- a/fs/crypto/hooks.c
> +++ b/fs/crypto/hooks.c
> @@ -255,10 +255,10 @@ int fscrypt_prepare_symlink(struct inode *dir, const char *target,
>          * for now since filesystems will assume it is there and subtract it.
>          */
>         if (!__fscrypt_fname_encrypted_size(policy, len,
> -                                           max_len - sizeof(struct fscrypt_symlink_data),
> +                                           max_len - sizeof(struct fscrypt_symlink_data) - 1,
>                                             &disk_link->len))
>                 return -ENAMETOOLONG;
> -       disk_link->len += sizeof(struct fscrypt_symlink_data);
> +       disk_link->len += sizeof(struct fscrypt_symlink_data) + 1;
>
>         disk_link->name = NULL;
>         return 0;
> @@ -289,7 +289,7 @@ int __fscrypt_encrypt_symlink(struct inode *inode, const char *target,
>                 if (!sd)
>                         return -ENOMEM;
>         }
> -       ciphertext_len = disk_link->len - sizeof(*sd);
> +       ciphertext_len = disk_link->len - sizeof(*sd) - 1;
>         sd->len = cpu_to_le16(ciphertext_len);
>
>         err = fscrypt_fname_encrypt(inode, &iname, sd->encrypted_path,
> @@ -367,7 +367,7 @@ const char *fscrypt_get_symlink(struct inode *inode, const void *caddr,
>          * the ciphertext length, even though this is redundant with i_size.
>          */
>
> -       if (max_size < sizeof(*sd))
> +       if (max_size < sizeof(*sd) + 1)
>                 return ERR_PTR(-EUCLEAN);
>         sd = caddr;
>         cstr.name = (unsigned char *)sd->encrypted_path;
> @@ -376,7 +376,7 @@ const char *fscrypt_get_symlink(struct inode *inode, const void *caddr,
>         if (cstr.len == 0)
>                 return ERR_PTR(-EUCLEAN);
>
> -       if (cstr.len + sizeof(*sd) - 1 > max_size)
> +       if (cstr.len + sizeof(*sd) > max_size)
>                 return ERR_PTR(-EUCLEAN);
>
>         err = fscrypt_fname_alloc_buffer(cstr.len, &pstr);
> --
> 2.34.1
>

Re: [PATCH] fscrypt: Replace 1-element array with flexible array

[Eric Biggers]

On Mon, May 22, 2023 at 02:39:28PM -0700, Kees Cook wrote:
> In the future, we can add annotations for the flexible array member
> "encrypted_path" to have a size determined by the "len" member.

That seems unlikely, as 'struct fscrypt_symlink_data' is an on-disk data
structure.  The "len" field does not necessarily use CPU endianness, and before
being validated it might be greater than the size of the allocated space.

I agree that it should use a flex array (and thanks for catching this one that I
had forgotten about...), but the above explanation seems wrong.

- Eric

Re: [PATCH] fscrypt: Replace 1-element array with flexible array

[Kees Cook]

On May 22, 2023 4:02:06 PM PDT, Eric Biggers <ebiggers@kernel.org> wrote:
>On Mon, May 22, 2023 at 02:39:28PM -0700, Kees Cook wrote:
>> In the future, we can add annotations for the flexible array member
>> "encrypted_path" to have a size determined by the "len" member.
>
>That seems unlikely, as 'struct fscrypt_symlink_data' is an on-disk data
>structure.  The "len" field does not necessarily use CPU endianness, and before
>being validated it might be greater than the size of the allocated space.

Oh yes, good point.

>I agree that it should use a flex array (and thanks for catching this one that I
>had forgotten about...), but the above explanation seems wrong.

Shall I spin a v2?


-- 
Kees Cook

Re: [PATCH] fscrypt: Replace 1-element array with flexible array

[Eric Biggers]

On Mon, May 22, 2023 at 06:23:06PM -0700, Kees Cook wrote:
> On May 22, 2023 4:02:06 PM PDT, Eric Biggers <ebiggers@kernel.org> wrote:
> >On Mon, May 22, 2023 at 02:39:28PM -0700, Kees Cook wrote:
> >> In the future, we can add annotations for the flexible array member
> >> "encrypted_path" to have a size determined by the "len" member.
> >
> >That seems unlikely, as 'struct fscrypt_symlink_data' is an on-disk data
> >structure.  The "len" field does not necessarily use CPU endianness, and before
> >being validated it might be greater than the size of the allocated space.
> 
> Oh yes, good point.
> 
> >I agree that it should use a flex array (and thanks for catching this one that I
> >had forgotten about...), but the above explanation seems wrong.
> 
> Shall I spin a v2?

Yes, please go ahead.

- Eric