GitLab

In branch devel, as of April 2015, the following lines in tests/unit/test_b64.c exert the function @otrl_base64_otr_decode()@ and to compare the produced buffer to an oracle.

	bufp = NULL;
	len = 0;

	ok(otrl_base64_otr_decode(alphanum_encoded, &bufp, &len) == 0,
			"Call with valid data successfull");
	ok(strcmp((const char*)bufp, alphanum_decoded) == 0
			&& len == 37, "Decoded valid b64 test vector with success");

With the input used, the function reconstitutes a message that is not 0-terminated. Assuming that this is normal behavior, then this message should not be passed to @strcmp@. @strcmp@ reads 38 bytes from @bufp@ in order to compare the buffer to @alphanum_decoded@. The last byte is uninitialized. Although @malloc()@ tends to produce blocks that contain 0, this behavior is not guaranteed. This means that the test will fail for some people on some platforms, undermining confidence in the tests.

A better condition at line 67 of test_b64.c would be instead something like @len == 37 && memcmp((const char*)bufp, alphanum_decoded, len) == 0@. This condition does not invoke undefined behavior as long as @otrl_base64_otr_decode()@ works as intended, and tries hard not to invoke undefined behavior if the function misbehaves, although any guarantee would be futile in the latter case.

This report is related to but differs from report 47 (https://bugs.otr.im/issues/47 ).

(from redmine: created on 2015-04-14)