Custom memory allocator that helps discover reads from uninitialized memory

I haven't been able to test this with uninitialized memory yet, because malloc keeps giving me zeroed buffers (even without this LD_PRELOADed). Perhaps gcc is messing with it?

This may be better suited for a separate repo, but I'm not really interested in maintaining it long term because I'm not planning on using it personally.

This also fixes all outstanding issues at the time of writing (#1 #2 #3).

The global counter inside malloc() sometimes might not be incremented in multi-threaded programs due to data races. This may result in uninitialized memory accesses in multi-threaded programs not being reliably detected.

It can be fixed by using atomic types from C11 standard. This will require including <stdatomic.h>, adding -std=c11 to compiler flags in Makefile, and probably replacing all alloc_clobber_counter++ with atomic_fetch_add(&alloc_clobber_counter, 1) but I'm not really sure about the details.

There are at least two superfluous checks this project has inherited from libdislocator:

1. Additional protected page is allocated at the end of each region. This crashes the binary on buffer overflows, but uses more memory than normal.
2. There is a global counter for the total amount of memory allocated, and at some point the library refuses to allocate any more. This is useful to detect a memory leak.

The primary reason I want to get rid of these is that I want to be sure that when a binary crashes under libdiffuzz and doesn't crash without it, it's because uninitialized memory is leaked into the output.

There are other excellent tools to isolate buffer overflows or memory leaks (asan, libdislocator), which should be used if those are the issues you're looking for.

Hey @Shnatsel,

I was trying to work out whether msan was giving me false positives when I happened upon libdiffuzz. It segfaulted immediately, but in a completely different part of the code.

I've isolated a small reproduceable test case here that uses toml and hashbrown to trigger the segfault: https://github.com/michaelsproul/hashbrown-crash

Have you seen segfaults like this before when using libdiffuzz? Is this a type of false positive, or is hashbrown really doing something sketchy with uninitialized memory? The fault seems to happen in an unsafe drop_in_place call, so I'm wondering whether hashbrown does contain some optimisation that assumes uninitialized memory to be 0, or something.

The full backtrace is here for reference:

#0  hashbrown::raw::RawIterRange<(alloc::vec::Vec<alloc::borrow::Cow<str>, alloc::alloc::Global>, alloc::vec::Vec<usize, alloc::alloc::Global>)>::new<(alloc::vec::Vec<alloc::borrow::Cow<str>, alloc::alloc::Global>, alloc::vec::Vec<usize, alloc::alloc::Global>)> (ctrl=0x7ffff7e2c0c8, data=..., len=<optimised out>) at /cargo/registry/src/github.com-1ecc6299db9ec823/hashbrown-0.12.0/src/raw/mod.rs:1862
#1  hashbrown::raw::RawTable<(alloc::vec::Vec<alloc::borrow::Cow<str>, alloc::alloc::Global>, alloc::vec::Vec<usize, alloc::alloc::Global>), alloc::alloc::Global>::iter<(alloc::vec::Vec<alloc::borrow::Cow<str>, alloc::alloc::Global>, alloc::vec::Vec<usize, alloc::alloc::Global>), alloc::alloc::Global> (self=0x7fffffffdbd8) at /cargo/registry/src/github.com-1ecc6299db9ec823/hashbrown-0.12.0/src/raw/mod.rs:945
#2  hashbrown::raw::RawTable<(alloc::vec::Vec<alloc::borrow::Cow<str>, alloc::alloc::Global>, alloc::vec::Vec<usize, alloc::alloc::Global>), alloc::alloc::Global>::drop_elements<(alloc::vec::Vec<alloc::borrow::Cow<str>, alloc::alloc::Global>, alloc::vec::Vec<usize, alloc::alloc::Global>), alloc::alloc::Global> (self=0x7fffffffdbd8) at /cargo/registry/src/github.com-1ecc6299db9ec823/hashbrown-0.12.0/src/raw/mod.rs:603
#3  0x0000555555562ca5 in hashbrown::raw::{impl#17}::drop<(alloc::vec::Vec<alloc::borrow::Cow<str>, alloc::alloc::Global>, alloc::vec::Vec<usize, alloc::alloc::Global>), alloc::alloc::Global> (self=0x7fffffffdbd8)
    at /cargo/registry/src/github.com-1ecc6299db9ec823/hashbrown-0.12.0/src/raw/mod.rs:1801
#4  core::ptr::drop_in_place<hashbrown::raw::RawTable<(alloc::vec::Vec<alloc::borrow::Cow<str>, alloc::alloc::Global>, alloc::vec::Vec<usize, alloc::alloc::Global>), alloc::alloc::Global>> ()
    at /rustc/fe5b13d681f25ee6474be29d748c65adcd91f69e/library/core/src/ptr/mod.rs:448
#5  core::ptr::drop_in_place<hashbrown::map::HashMap<alloc::vec::Vec<alloc::borrow::Cow<str>, alloc::alloc::Global>, alloc::vec::Vec<usize, alloc::alloc::Global>, std::collections::hash::map::RandomState, alloc::alloc::Global>>
    () at /rustc/fe5b13d681f25ee6474be29d748c65adcd91f69e/library/core/src/ptr/mod.rs:448
#6  core::ptr::drop_in_place<std::collections::hash::map::HashMap<alloc::vec::Vec<alloc::borrow::Cow<str>, alloc::alloc::Global>, alloc::vec::Vec<usize, alloc::alloc::Global>, std::collections::hash::map::RandomState>> ()
    at /rustc/fe5b13d681f25ee6474be29d748c65adcd91f69e/library/core/src/ptr/mod.rs:448
#7  toml::de::{impl#0}::deserialize_any<hashbrown_crash::_::{impl#0}::deserialize::__Visitor> (self=0x7fffffffdc68, visitor=...) at /home/michael/.cargo/registry/src/github.com-1ecc6299db9ec823/toml-0.5.9/src/de.rs:244
#8  toml::de::{impl#0}::deserialize_struct<hashbrown_crash::_::{impl#0}::deserialize::__Visitor> (self=0x7fffffffdc68, name=..., fields=..., visitor=...)
    at /home/michael/.cargo/registry/src/github.com-1ecc6299db9ec823/toml-0.5.9/src/de.rs:315
#9  0x000055555555fa3e in hashbrown_crash::_::{impl#0}::deserialize<&mut toml::de::Deserializer> (__deserializer=0x7fffffffdc68) at src/main.rs:3
#10 toml::de::from_str<hashbrown_crash::Input> (s=...) at /home/michael/.cargo/registry/src/github.com-1ecc6299db9ec823/toml-0.5.9/src/de.rs:80
#11 0x000055555555e4cd in hashbrown_crash::main () at src/main.rs:11

Currently libdiffuzz switches to non-deterministic mode after reading an environment variable from a function called from link-time "constructors" section:

https://github.com/Shnatsel/libdiffuzz/blob/f0c7a8f3b27df24d389d9e003ebda01ad89eb1cf/src/lib.rs#L31-L33

This is not a great idea for two reasons:

1. This is not portable. This is already taking different codepaths depending on whether it's on Linux/BSD or macOS. Windows is currently not supported. What's worse, there is no way to tell if this actually works on your platform or not!
2. This may kick in too late and miss initializing some heap-allocated memory in other libraries with similar hooks, so libdiffuzz will fail to expose some errors.

libdiffuzz doesn't make much use of the standard library. It can probably be switched to the corresponding libcore primitives and compiled in #![no_std] mode.

Among other things, this will reduce the size of the generated binary and may allow cross-compilation to the more obscure architectures.

It would be nice to be able to detect out-of-bounds reads as well. This is actually pretty easy to implement - just allocate more memory than was requested and clobber it with the same variable value as the rest of the buffer. If any of the clobbered values show up in the output, then the program is definitely exploitable - either via reads from uninitialized memory or via out-of-bounds reads.

Use case: I needed this functionality to determine whether https://github.com/sile/libflate/issues/16 is exploitable or not.

I have already implemented checks for out-of-bounds reads to the right of the buffer in branch detect-oob-reads, but the ones to the left are still TODO - there's just a static canary there that's inherited from libdislocator.