| Message ID | 20230522213924.never.119-kees@kernel.org (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | fscrypt: Replace 1-element array with flexible array | expand |
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 >
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 <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?
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
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);
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(-)