OPENSSL_MALLOC(3ossl)
π OPENSSL_MALLOC π
okay so bestie, this is OPENSSL_MALLOC(3ossl) β the manual page for literally every memory-allocation function OpenSSL has π it's a long one so we're doing it in parts, but don't worry, I got you. grab a snack π
β¨ NAME β¨ β the whole squad, roll call π
Here's everybody this page is about, no one gets left behind:
OPENSSL_malloc_initOPENSSL_mallocOPENSSL_aligned_allocOPENSSL_zallocOPENSSL_reallocOPENSSL_freeOPENSSL_clear_reallocOPENSSL_clear_freeOPENSSL_cleanseCRYPTO_mallocCRYPTO_aligned_allocCRYPTO_zallocCRYPTO_reallocCRYPTO_freeOPENSSL_strdupOPENSSL_strndupOPENSSL_memdupOPENSSL_strlcpyOPENSSL_strlcatOPENSSL_strtoulCRYPTO_strdupCRYPTO_strndupOPENSSL_mem_debug_pushOPENSSL_mem_debug_popCRYPTO_mem_debug_pushCRYPTO_mem_debug_popCRYPTO_clear_reallocCRYPTO_clear_freeCRYPTO_malloc_fnCRYPTO_realloc_fnCRYPTO_free_fnCRYPTO_get_mem_functionsCRYPTO_set_mem_functionsCRYPTO_get_alloc_countsCRYPTO_set_mem_debugCRYPTO_mem_ctrlCRYPTO_mem_leaksCRYPTO_mem_leaks_fpCRYPTO_mem_leaks_cbOPENSSL_MALLOC_FAILURESOPENSSL_MALLOC_FD
...and their collective vibe? Memory allocation functions. that's it, that's the thesis π
πΈ SYNOPSIS πΈ
#include <openssl/crypto.h>
int OPENSSL_malloc_init(void);
void *OPENSSL_malloc(size_t num);
void *OPENSSL_aligned_alloc(size_t num, size_t alignment, void **freeptr);
void *OPENSSL_zalloc(size_t num);
void *OPENSSL_realloc(void *addr, size_t num);
void OPENSSL_free(void *addr);
char *OPENSSL_strdup(const char *str);
char *OPENSSL_strndup(const char *str, size_t s);
size_t OPENSSL_strlcat(char *dst, const char *src, size_t size);
size_t OPENSSL_strlcpy(char *dst, const char *src, size_t size);
int OPENSSL_strtoul(char *src, char **endptr, int base, unsigned long *num);
void *OPENSSL_memdup(void *data, size_t s);
void *OPENSSL_clear_realloc(void *p, size_t old_len, size_t num);
void OPENSSL_clear_free(void *str, size_t num);
void OPENSSL_cleanse(void *ptr, size_t len);
void *CRYPTO_malloc(size_t num, const char *file, int line);
void *CRYPTO_aligned_alloc(size_t num, size_t align, void **freeptr,
const char *file, int line);
void *CRYPTO_zalloc(size_t num, const char *file, int line);
void *CRYPTO_realloc(void *p, size_t num, const char *file, int line);
void CRYPTO_free(void *str, const char *, int);
char *CRYPTO_strdup(const char *p, const char *file, int line);
char *CRYPTO_strndup(const char *p, size_t num, const char *file, int line);
void *CRYPTO_clear_realloc(void *p, size_t old_len, size_t num,
const char *file, int line);
void CRYPTO_clear_free(void *str, size_t num, const char *, int);
typedef void *(*CRYPTO_malloc_fn)(size_t num, const char *file, int line);
typedef void *(*CRYPTO_realloc_fn)(void *addr, size_t num, const char *file,
int line);
typedef void (*CRYPTO_free_fn)(void *addr, const char *file, int line);
void CRYPTO_get_mem_functions(CRYPTO_malloc_fn *malloc_fn,
CRYPTO_realloc_fn *realloc_fn,
CRYPTO_free_fn *free_fn);
int CRYPTO_set_mem_functions(CRYPTO_malloc_fn malloc_fn,
CRYPTO_realloc_fn realloc_fn,
CRYPTO_free_fn free_fn);
void CRYPTO_get_alloc_counts(int *mcount, int *rcount, int *fcount);
env OPENSSL_MALLOC_FAILURES=... <application>
env OPENSSL_MALLOC_FD=... <application>
and now the tea β β the following functions have been deprecated since OpenSSL 3.0, and you can hide them entirely by defining OPENSSL_API_COMPAT with a suitable version value, see openssl_user_macros(7):
int CRYPTO_mem_leaks(BIO *b);
int CRYPTO_mem_leaks_fp(FILE *fp);
int CRYPTO_mem_leaks_cb(int (*cb)(const char *str, size_t len, void *u),
void *u);
int CRYPTO_set_mem_debug(int onoff);
int CRYPTO_mem_ctrl(int mode);
int OPENSSL_mem_debug_push(const char *info);
int OPENSSL_mem_debug_pop(void);
int CRYPTO_mem_debug_push(const char *info, const char *file, int line);
int CRYPTO_mem_debug_pop(void);
π¦ DESCRIPTION π¦
So. OpenSSL memory allocation runs through the OPENSSL_xxx API. Those are generally macros β they sneak the standard C __FILE__ and __LINE__ params in for you and then call down to the lower-level CRYPTO_xxx API β¨ A few functions don't add those params at all, but they exist anyway, purely for consistency. (respect, honestly.)
OPENSSL_malloc_init() does literally nothing and you don't need to call it. It's just hanging around for compatibility with older versions of OpenSSL π
OPENSSL_malloc(), OPENSSL_realloc(), and OPENSSL_free() are like the C malloc(), realloc(), and free() functions β same energy. And OPENSSL_zalloc() calls memset() to zero the memory before it hands it back to you π«Ά
OPENSSL_aligned_alloc() works just like OPENSSL_malloc does, except it lets you specify an alignment value β for the situations where malloc's default alignment just isn't giving what your caller needs π
heads up though: the alignment value must be a power of 2, and the size you specify must be a multiple of the alignment. NOTE: the call to OPENSSL_aligned_alloc() takes a 3rd argument, freeptr, which must point to a void pointer. On some platforms there's no library call available to get you memory allocations bigger than what malloc provides. When that happens, OPENSSL_aligned_alloc implements its own alignment routine β it allocates extra memory and offsets the returned pointer so it lands on the requested alignment boundary. And to safely free allocations made this way, the caller must return the value in the freeptr variable, not the returned pointer. no cap, that part matters π
OPENSSL_clear_realloc() and OPENSSL_clear_free() are the ones you want when the buffer at addr is holding sensitive information. The old buffer gets filled with zero's by calling OPENSSL_cleanse() before it ultimately calls OPENSSL_free(). And if the argument to OPENSSL_clear_free() is NULL? Nothing happens. chill. π§
OPENSSL_cleanse() fills ptr of size len with a string of 0's. Super useful when you need to make sure memory that contains sensitive information actually gets overwritten β for example before it's reclaimed, or when it's stored on the stack β and you need that operation to not get optimised out by compiler optimisations like dead store elimination (which memset(3) may totally get hit by π).
Use OPENSSL_cleanse() with care if the memory is a mapping of a file. If the storage controller uses write compression, then it's possible that sensitive tail bytes will survive zeroization, because the block of zeros will be compressed. And if the storage controller uses wear leveling, then the old sensitive data will not be overwritten β instead, a block of 0's gets written at a new physical location. π scary but true.
OPENSSL_strdup(), OPENSSL_strndup() and OPENSSL_memdup() are like the equivalent C functions, except the memory is allocated by calling OPENSSL_malloc() and should be released by calling OPENSSL_free(). matching set, as it should be π
OPENSSL_strlcpy(), OPENSSL_strlcat() and OPENSSL_strnlen() are equivalents of the common C library functions, and they're provided for portability π
OPENSSL_strtoul() is a wrapper around the POSIX function strtoul, with the same behaviors listed in the POSIX documentation β plus extra behaviour of its own: it validates the input str and num parameters for not being NULL, and it confirms that at least a single byte of input has been consumed in the translation, returning an error in the event that no bytes were consumed. thorough queen π
If no allocations have been done, it is possible to "swap out" the default implementations for OPENSSL_malloc(), OPENSSL_realloc() and OPENSSL_free() and replace them with alternate versions. The CRYPTO_get_mem_functions() function fills in the given arguments with the function pointers for the current implementations. With CRYPTO_set_mem_functions(), you can specify a different set of functions. If any of malloc_fn, realloc_fn, or free_fn are NULL, then that function is not changed. And while it's permitted to swap out only a few and not all of the functions with CRYPTO_set_mem_functions(), it's recommended to swap them all out at once. all or nothing bestie β¨
If the library is built with the "crypto-mdebug" option, then one function β CRYPTO_get_alloc_counts() β and two additional environment variables, OPENSSL_MALLOC_FAILURES and OPENSSL_MALLOC_FD, are available π
The function CRYPTO_get_alloc_counts() fills in the number of times each of CRYPTO_malloc(), CRYPTO_realloc(), and CRYPTO_free() have been called, into the values pointed to by mcount, rcount, and fcount, respectively. If a pointer is NULL, then the corresponding count is not stored. simple π
The variable OPENSSL_MALLOC_FAILURES controls how often allocations should fail. It's a set of fields separated by semicolons, where each field is a count (defaulting to zero) and an optional atsign and percentage (defaulting to 100). If the count is zero, then it lasts forever. For example, "100;@25" or "100@0;0@25" means the first 100 allocations pass, then all other allocations (until the program exits or crashes) have a 25% chance of failing. The length of the value of OPENSSL_MALLOC_FAILURES must be 256 or fewer characters. don't push it π«
If the variable OPENSSL_MALLOC_FD is parsed as a positive integer, then it's taken as an open file descriptor. This gets used in conjunction with OPENSSL_MALLOC_FAILURES described above. For every allocation it will log details about how many allocations there have been so far, what percentage chance there is for this allocation failing, and whether it has actually failed. The following example in classic shell syntax shows how to use this (and no, it will not work on all platforms, sorry babes π):
OPENSSL_MALLOC_FAILURES='200;@10'
export OPENSSL_MALLOC_FAILURES
OPENSSL_MALLOC_FD=3
export OPENSSL_MALLOC_FD
...app invocation... 3>/tmp/log$$
β¨ RETURN VALUES β¨
Okay bestie, here's the receipts on what each function hands back. Some of these are giving silent treatment, some are giving pointers, and some are giving deprecated chaos. π
OPENSSL_malloc_init(),OPENSSL_free(),OPENSSL_clear_free(),CRYPTO_free(),CRYPTO_clear_free()andCRYPTO_get_mem_functions()return no value. They're just out here doing their thing, no return arc. periodt.OPENSSL_malloc(),OPENSSL_aligned_alloc(),OPENSSL_zalloc(),OPENSSL_realloc(),OPENSSL_clear_realloc(),CRYPTO_malloc(),CRYPTO_zalloc(),CRYPTO_realloc(),CRYPTO_clear_realloc(),OPENSSL_strdup(), andOPENSSL_strndup()return a pointer to allocated memory, orNULLon error. So if you getNULL, it's not a vibe β handle it. πCRYPTO_set_mem_functions()returns1on success or0on failure (almost always because allocations have already happened). So if you're trying to set memory functions after stuff already allocated? Yeah, that's a no. πCRYPTO_mem_leaks(),CRYPTO_mem_leaks_fp(),CRYPTO_mem_leaks_cb(),CRYPTO_set_mem_debug(), andCRYPTO_mem_ctrl()are deprecated and are no-ops that always return-1. MeanwhileOPENSSL_mem_debug_push(),OPENSSL_mem_debug_pop(),CRYPTO_mem_debug_push(), andCRYPTO_mem_debug_pop()are also deprecated and are no-ops that always return0. Not them being useless on purpose, but yes exactly that. πOPENSSL_strtoul()returns1on success and0if an error has occurred. Specifically,0is returned in these events:- If the underlying call to
strtoulreturned a non zeroerrnovalue. - If the translation did not consume the entire input string, and the passed
endptrvalue wasNULL. - If no characters were consumed in the translation.
- If the underlying call to
Big heads up bestie: a success condition does not imply that the expected translation has been performed. For instance calling
OPENSSL_strtoul("0x12345", &endptr, 10, &num);
will result in a successful translation with num having the value 0, and *endptr = 'x'. So be sure to validate how much data was consumed when calling this function. It's giving "success but read the fine print." π«Ά
πΈ HISTORY πΈ
Okay so lore time. OPENSSL_mem_debug_push(), OPENSSL_mem_debug_pop(), CRYPTO_mem_debug_push(), CRYPTO_mem_debug_pop(), CRYPTO_mem_leaks(), CRYPTO_mem_leaks_fp(), CRYPTO_mem_leaks_cb(), CRYPTO_set_mem_debug(), and CRYPTO_mem_ctrl() were deprecated in OpenSSL 3.0. The memory-leak checking has been deprecated in OpenSSL 3.0 in favor of clang's memory and leak sanitizer. And OPENSSL_aligned_alloc(), CRYPTO_aligned_alloc(), and OPENSSL_strtoul() were added in OpenSSL 3.4. So yeah, glow-up timeline. β¨
π COPYRIGHT π
Copyright 2016-2026 The OpenSSL Project Authors. All Rights Reserved.
Licensed under the Apache License 2.0 (the "License"). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.
This page is from OpenSSL 3.5.9, dated 2026-09-29, and it's the OPENSSL_MALLOC(3ossl) manual page. Stay allocated, bestie. πβ¨
π¦ where this page comes from
- fedora 43: openssl-devel 1:3.5.9-1.fc43 Β· Apache-2.0
- fedora 43: openssl-devel 1:3.5.9-1.fc43 Β· Apache-2.0
- fedora 44: openssl-devel 1:3.5.9-1.fc44 Β· Apache-2.0
- fedora 44: openssl-devel 1:3.5.9-1.fc44 Β· Apache-2.0
- π girlified by deepseek-ai/DeepSeek-V4.1-Flash on : a language model's rewrite of the original, under its terms