[derefr]

OpenSSL has an abstraction layer over malloc, which uses an internal stack-based free-list, and which it uses for all allocations. It's not an actual malloc(3) implementation, which is half the problem.

If OpenSSL had just written a malloc(3) implementation that sat in a separate shared-object--the way that, for example, jemalloc does--then switching it out would be a simple and obvious linker argument. Any developer who had used a project that relies on an alternate malloc (e.g. redis) would know that "test while linked against system malloc" is a crucial step.

Instead, you have to learn that there's a specific OpenSSL debugging flag that disables the "caching behavior" of the malloc wrapper, causing it to become a passthrough to regular malloc. None of the tests use this flag.

[cmbaus]

> OpenSSL has an abstraction layer over malloc, which uses an internal stack-based free-list, and which it uses for all allocations

To be clear, this is NOT TRUE. The freelist is used for some allocations, but not in the patch in point. Here is the patch that addresses the bug: https://github.com/openssl/openssl/commit/731f431497f463f3a2...

It clearly uses OPENSSL_Malloc which is basically the equivalent of calling malloc.

https://github.com/openssl/openssl/commit/731f431497f463f3a2...

[cmbaus]

Here's where the freelist operations are defined: https://github.com/openssl/openssl/blob/21e0c1d23afff48601eb...

But where are they called from?

Update: To answer my own question the freelist is used in

    ssl3_setup_read_buffer()
    ssl3_release_read_buffer()
    ssl3_setup_writer_buffer()
    ssl3_release_write_buffer()

This is not the same as universally replacing the allocator.