Skip to content

GitLab

  • Menu
Projects Groups Snippets
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • L libotr
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 50
    • Issues 50
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 0
    • Merge requests 0
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • Libraries
  • libotr
  • Issues
  • #91

Closed
Open
Created Apr 01, 2016 by PascalCuoq@pascal_cuoq

libotr's tests/unit/test_b64.c invokes undefined behavior, may fail arbitrarily on some platforms

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)

To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
Time tracking