Re: [PATCH] lib/crypto: sha1: Explicitly specify alignment of sha1_ctx::buf

[Eric Biggers]

On Fri, Mar 20, 2026 at 04:14:03PM -0700, Eric Biggers wrote:
> __sha1_final() writes a __be64 to &ctx->buf[56] using a plain write.
> That assumes that the alignment of buf is at least that of __be64.  It
> is, since it immediately follows a u64 field.  However, to make this
> assumption explicit it's best to specify the field alignment explicitly
> too, like what is done in the corresponding SHA-2 and MD5 structs.
> 
> Signed-off-by: Eric Biggers <ebiggers@xxxxxxxxxx>
> ---
>  include/crypto/sha1.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/include/crypto/sha1.h b/include/crypto/sha1.h
> index 4d973e016cd6..560ed4fd1703 100644
> --- a/include/crypto/sha1.h
> +++ b/include/crypto/sha1.h
> @@ -38,11 +38,11 @@ struct sha1_block_state {
>   * @buf: partial block buffer; bytecount % SHA1_BLOCK_SIZE bytes are valid
>   */
>  struct sha1_ctx {
>  	struct sha1_block_state state;
>  	u64 bytecount;
> -	u8 buf[SHA1_BLOCK_SIZE];
> +	u8 buf[SHA1_BLOCK_SIZE] __aligned(__alignof__(__be64));
>  };

Surprisingly, this patch actually breaks the build on 32-bit x86.  The
static assertions in crypto/sha1.c that verify the consistency of
'struct sha1_ctx' and 'struct sha1_state' start failing.  gcc puts
bytecount and buf at offsets 20 and 28 in the struct.  I.e., it puts the
u64 field on only a 4-byte boundary.  However, __alignof__(__be64)
actually returns 8, causing the offset of buf to change from 28 to 32.
(The result is the same if __alignof__(u64) is used instead.)

Apparently __alignof__ returns the "preferred alignment".  But what we
want is "minimum alignment".  Which is C11's _Alignof, which was
deprecated in C23 and replaced with "alignof".  Sigh.

Probably best to just keep this as-is until we can get drivers/crypto/
migrated off of 'struct sha1_state' and remove that.

- Eric