On Mon, Apr 08, 2019 at 10:27:37AM -0700, Eric Biggers wrote: > > It's not just LRW though. It's actually 7 places: > > arch/arm/crypto/aes-neonbs-glue.c > arch/arm/crypto/chacha-neon-glue.c > arch/arm64/crypto/aes-neonbs-glue.c > arch/arm64/crypto/chacha-neon-glue.c > crypto/chacha-generic.c > crypto/lrw.c > crypto/salsa20-generic.c > > Do you prefer that all those be updated? We have to because if memory allocation fails then walk->iv will just be the origial IV. If you can use the original IV then you might as well just do that. I just checked chacha-generic and it is fine as it's using the original IV and not walk->iv (the difference is that one may be unaligned while the other is guaranteed to be aligned). arm*/chacha-neon-glue.c are also correct. salsa20 is indeed broken but the fix is trivial since it's already using unaligned loads. arm/aes-neonbs-glue seems easily fixed as it can simply use the unaligned original IV since it's going through the crypto API again. arm64/aes-neonbs-glue I'm not quite sure as it's calling into assembly so depending on whether that wants aligned/unaligned this can either use the original IV or check for errors and abort if necessary. Cheers, -- Email: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
