CVE Case Studies
This section demonstrates how compatmalloc's hardening features detect and prevent exploitation techniques used in real-world CVEs affecting glibc's heap allocator.
Methodology
For each CVE, we provide:
- A minimal proof-of-concept (C program in
tests/cve/) that demonstrates the exploitation technique - Side-by-side output showing behavior under glibc vs. compatmalloc
- Analysis of which hardening features provide protection and their limitations
Honest assessment
compatmalloc is an open-source project aiming to improve. Where our hardening has limitations, we document them. Our software canary checks detect overflows on free(), not at the moment of overflow. Our quarantine detects write-after-free on eviction, not at the moment of write. On ARM64 hardware with Memory Tagging Extension (MTE), these limitations are eliminated — overflows and use-after-free are detected immediately at the point of access. On hardware without MTE, the software mechanisms provide equivalent coverage with delayed detection.
Case studies
| CVE | CVSS | Technique | compatmalloc detection |
|---|---|---|---|
| CVE-2024-2961 | 8.8 | Buffer overflow / tcache poisoning | Canary check + out-of-band metadata |
| CVE-2023-6246 | 7.8 | Heap buffer overflow / metadata corruption | Canary check + guard pages |
| Double-free | -- | Double-free / tcache dup | Metadata FLAG_FREED check |
Running the demos
# Build compatmalloc
cargo build --release
# Run all CVE demos
./tests/cve/run_demos.sh
# Run a specific demo
gcc -o /tmp/demo tests/cve/double_free.c
# With glibc:
/tmp/demo
# With compatmalloc:
LD_PRELOAD=./target/release/libcompatmalloc.so /tmp/demo