>>> OpenSSL 1.0.2e >>> >>> At line 156 of crypto/modes/ctr128.c >>> >>> const unsigned char *in, >>> unsigned char *out, >>> unsigned char ivec[16], >>> unsigned char ecount_buf[16] >>> >>> *(size_t *)(out + n) = >>> *(size_t *)(in + n) ^ *(size_t *)(ecount_buf + n); >>> >>> If the buffers are not aligned, the application crashes due to the invalid >>> type casting of unsigned char (1 byte) to size_t (4 to 8 bytes for most >>> CPU:s). >> >> You should not run into that issue if STRICT_ALIGNMENT is defined. > > Well, yes, except that it doesn't check for alignment of ecount_buf. I > mean there is 'if' clause for STRICT_ALIGNMENT that ensures that in, out > and ivec are aligned, but not ecount_buf. And judging from crash report, > it is ecount_buf that is not properly aligned (see last displayed > argument). So that original analysis is sane. It should be noted that it > looks like subroutine in question is called from application directly. > While if called from EVP, i.e. the usual way, the problem never occurs, > because that buffer is properly aligned within EVP_CIPHER_CTX structure. > Resolution will follow later...
http://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=5e4bbeb49fb6522d858703201b5adee9611e7b7b. Closing ticket. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4218 Please log in as guest with password guest if prompted -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
