ACCESS TO IT INTEL GRANTED

Trigger and confirm a double-free with MALLOC_CHECK_ and glibc abort

TARGET_ENV: Ubuntu 20.04/22.04, Debian 11/12, glibc 2.31+
[ TAGS: heap, snippet, glibc, double-free, fuzzing, debugging, malloc ]

Setting the MALLOC_CHECK_ environment variable to 3 makes glibc install consistency checks around malloc and free, aborting the process via __libc_message when it detects corruption such as a double free or an invalid next size. Internally, glibc's malloc interposes additional validation in _int_free that inspects the chunk size, the next chunk's prev_inuse bit, and the fastbin/tcache entry it is about to link, then calls malloc_printerr on violation.

This is used during fuzzing and development to catch heap corruption early rather than at a later crash, giving a clear stack trace pointing to the offending free call. It is standard practice in CI pipelines for C and C++ services that manage buffers manually, and in CTF preparation to quickly identify whether a primitive is a true double-free.

Security implications: MALLOC_CHECK_ is a debugging aid, not a mitigation, and it does not protect against all corruption; attackers can still exploit races or corrupt metadata that passes the checks. Performance overhead is significant, often 2x to 5x on allocation-heavy workloads, so never enable it in production. A common pitfall is that some checks only fire on the second free, so the initial corruption may go unnoticed; also, MALLOC_CHECK_ is ignored when setuid or setgid bits are present for security reasons.

> System.Execute()

MALLOC_CHECK_=3 MALLOC_PERTURB_=165 ./vuln_binary 2>&1 | tee heap_crash.log; echo "exit=$?"

> Architecture & Security Context

Verified for Valters IT Hub. When deploying this configuration in a production homelab or enterprise environment, ensure that you monitor system resources and implement strict access controls. Administrator privileges are required.


ID: VALTERSIT-CFB6D2962552

← BACK_TO_VAULT → CVE_DATABASE