This is an archive of the discontinued LLVM Phabricator instance.

[scudo] Fix bad request handling when allocator has not been initialized
ClosedPublic

Authored by cryptoad on Sep 14 2017, 10:41 AM.

Details

Summary

In a few functions (scudoMemalign and the like), we would call
ScudoAllocator::FailureHandler::OnBadRequest if the parameters didn't check
out. The issue is that if the allocator had not been initialized (eg: if this
is the first heap related function called), we would use variables like
allocator_may_return_null and exitcode that still had their default value
(as opposed to the one set by the user or the initialization path).

To solve this, we introduce handleBadRequest that will call initThreadMaybe,
allowing the options to be correctly initialized.

Unfortunately, the tests were passing because exitcode was still 0, so the
results looked like success. Change those tests to do what they were supposed
to.

Event Timeline

cryptoad created this revision.Sep 14 2017, 10:41 AM
alekseyshl edited edge metadata.Sep 14 2017, 11:30 AM

Would moving SetAllocatorMayReturnNull call earler in the init() function help to resolve the problem?

Would moving SetAllocatorMayReturnNull call earler in the init() function help to resolve the problem?

Unfortunately, prior to this change, init might not be called at all. This would be the case for the following pseudo-example:

int main(void) {
  void *p = memalign(3, 3);
  return 0;
}

We would go directly to ScudoAllocator::FailureHandler::OnBadRequest without going through initThread -> initScudo -> initFlags.

I should add for completeness sake that to be fair, it's not a "real life" issue, as it would require the first heap operation ever called to be wrong.
But it's not a proper behavior.

alekseyshl accepted this revision.Sep 14 2017, 1:34 PM

Ah, right, makes sense.

This revision is now accepted and ready to land.Sep 14 2017, 1:34 PM
cryptoad closed this revision.Sep 14 2017, 1:35 PM