Changing the movzwl to movzbl in bn_get_bits5 eliminates the valgrind error. But this isn't a valid fix since bn_get_bits5 no longer returns the correct data. My assembly skills are near nil. Maybe someone else can propose a valid fix.
Having said this, this does show the problem appears to be due to the movzwl reading past the end of the buffer by a byte. Given the data allocated on the heap is likely surrounded by guard bytes, this is likely a benign read outside the buffer. But it should still be fixed. On 05/13/2015 10:46 AM, John Foley wrote: > Sorry for misinterpreting your question, my mistake. I was able to > replicate the error. It looks like the invalid read is in code that's > compiled in when OPENSSL_BN_ASM_MONT5 is set, which is only for the > X86_64 target. Looking at the diff of x86_64-mont5.pl between 1.0.1 and > 1.0.2, there are quite a few changes. My guess is this was introduced > in ec9cc70f72454b8d4a84247c86159613cee83b81. > > > > > On 05/13/2015 10:13 AM, Henrik Grindal Bakken wrote: >> John Foley <fol...@cisco.com> writes: >> >>> If you add the --show-reachable option to valgrind, you can see where >>> the leaks originate. They appear to be in the ex_data code (see >>> below). As a side note, I see 416 bytes lost when using OpenSSL 1.0.1f >>> as well as 1.0.2a. >> Ah, I forgot to mention. I'm not concerned about the leak, but the >> invalid read that's in 1.0.2 only. >> >> This one: >> >>>> ==14854== Invalid read of size 2 >>>> ==14854== at 0x4F09198: bn_get_bits5 (in >>>> /home/henribak/src/thirdparty/openssl/libcrypto.so.1.0.0) >>>> ==14854== by 0x4F32B47: generate_key (in >>>> /home/henribak/src/thirdparty/openssl/libcrypto.so.1.0.0) >>>> ==14854== by 0x400A30: main (in /home/henribak/tmp/dh-1.0.2) > > _______________________________________________ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > _______________________________________________ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev