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 <[email protected]>
Cc: "Theodore Y. Ts'o" <[email protected]>
Cc: Jaegeuk Kim <[email protected]>
Cc: Gustavo A. R. Silva <[email protected]>
Cc: [email protected]
Signed-off-by: Kees Cook <[email protected]>
---
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
On Mon, May 22, 2023 at 2:39 PM Kees Cook <[email protected]> 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 <[email protected]>
> Cc: "Theodore Y. Ts'o" <[email protected]>
> Cc: Jaegeuk Kim <[email protected]>
> Cc: Gustavo A. R. Silva <[email protected]>
> Cc: [email protected]
> Signed-off-by: Kees Cook <[email protected]>
Reviewed-By: Bill Wendling <[email protected]>
(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
>
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
On May 22, 2023 4:02:06 PM PDT, Eric Biggers <[email protected]> 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
On Mon, May 22, 2023 at 06:23:06PM -0700, Kees Cook wrote:
> On May 22, 2023 4:02:06 PM PDT, Eric Biggers <[email protected]> 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