A security-focused memory allocator providing hardened malloc API with extensive heap corruption protections for modern 64-bit systems.
hardened_malloc is a security-focused replacement for standard memory allocators like glibc's malloc, jemalloc, and others. It provides extensive hardening against heap corruption vulnerabilities such as use-after-free, double-free, and buffer overflows while maintaining reasonable performance. It is designed for modern 64-bit systems and integrates with Android's Bionic libc, musl, and glibc.
System developers, security engineers, and maintainers of Android/Linux-based operating systems who need a production-ready allocator with strong security guarantees against memory corruption exploits.
Developers choose hardened_malloc for its comprehensive security features that go beyond typical allocators, offering deterministic protections, out-of-line metadata, and fine-grained randomization. It is a strict upgrade over traditional allocators for threat models where security is prioritized over raw allocation speed.
Hardened allocator designed for modern systems. It has integration into Android's Bionic libc and can be used externally with musl and glibc as a dynamic library for use on other Linux-based platforms. It will gain more portability/integration over time.
Open-Awesome is built by the community, for the community. Submit a project, suggest an awesome list, or help improve the catalog on GitHub.
Implements deterministic protections against use-after-free, double-free, and buffer overflows via out-of-line metadata, guard pages, and quarantines, as outlined in the security properties section.
Integrates ARM MTE for probabilistic and deterministic memory safety on supported hardware, with features like random tags and dedicated free-slot tags to detect overflows and use-after-free.
Uses fine-grained size classes and slab allocations to minimize internal and external memory waste, with detailed tables showing low fragmentation rates compared to traditional allocators.
Guarantees detection of any invalid free (unaligned, unallocated, etc.) and validates sizes for C++ deallocation to catch type confusion bugs, as noted in the core design.
Security features like zero-on-free, slab canaries, and guard pages incur measurable performance costs, especially for small allocations, with the README admitting trade-offs in configuration options.
Requires non-trivial setup, such as increasing vm.max_map_count and ensuring specific kernel and libc versions, which can be cumbersome for quick deployments or containerized environments.
Lacks thread-local caches for performance optimization, which the README explicitly states is incompatible with security features like quarantines and can hurt scalability in high-allocation workloads.
Exclusive to 64-bit systems with recent dependencies (e.g., Linux 6.12, glibc 2.41), and lacks support for 16k/64k ARM pages or 32-bit environments, restricting portability.