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,