`std::hint::black_box` does not work?

[Marcono1234]

Problem

It seems using black_box in fuzz targets does not have the desired effect, when it is used invalid memory access is not detected when running with cargo fuzz run --sanitizer=memory ....

Therefore (assuming I did not make a mistake in my test setup) I would be useful to:

• mention prominently in the documentation that black_box should not be used for fuzz tests
• mention alternatives
  • something like println! works but probably has quite some overhead
  • fuzz_target! does not support a return value (respectively only supports Corpus)
    It might therefore be useful if libfuzzer-sys offerred some kind of "black box" function?
    (have also asked on the forum for alternatives now)

Reproduction steps

Version information:

Ubuntu 24.04
Linux Kernel 6.6.87.2-microsoft-standard-WSL2
cargo 1.94.0-nightly (6d1bd93c4 2026-01-10)
cargo-fuzz 0.13.1

Steps:

1. mkdir fuzztest
2. cd fuzztest
3. cargo init --lib
4. cargo fuzz init
5. Edit fuzz/fuzz_targets/fuzz_target_1.rs:

   #![no_main]
   
   use libfuzzer_sys::fuzz_target;
   
   fuzz_target!(|data: &[u8]| {
       unsafe {
           let a = std::mem::MaybeUninit::<[usize; 4]>::uninit();
           let a = a.assume_init();
           std::hint::black_box(a[2]);
       }
   });

6. cargo +nightly fuzz run --sanitizer=memory fuzz_target_1 -- -runs=5
   ❌ Bug: No memory error is detected
7. Change fuzz_target_1.rs:

             let a = a.assume_init();
   -         std::hint::black_box(a[2]);
   +         println!("{}", a[2]);
         }

8. cargo +nightly fuzz run --sanitizer=memory fuzz_target_1 -- -runs=5
   ℹ️ As expected: The memory error is detected

Notes:

• While this is a quite contrived example, I had originally noticed this when fuzzing a compression library where it made a difference as well whether I passed the result to black_box vs println!.
• For this simple example using cargo fuzz run ... --dev helps; for the actual compression library I am fuzzing it does not seem to help.

[Marcono1234]

Or is this maybe not actually black_box vs. println!, and rather in both cases invalid memory access occurs but MemorySanitizer is not guaranteed to detect all cases (and somehow the different generated code makes a differences)?

[Marcono1234]

For the actual compression library I am fuzzing I had a closer look now at where the MemorySanitizer reports the invalid access. Apparently it is not actually within the decompression function which returns Vec<u8> but instead within println! when it accesses the contents of the vec¹.

So doing something like the following, and running it with --dev, actually works now:

let decomp = ...;
for byte in decomp {
    std::hint::black_box(byte);
}

But still this leaves two problems / inconveniences:

• it requires using --dev
• it requires manually consuming all parts of the result, to ensure there is a read access
  Respectively, doing something like format!("{result:?}") (assuming it implements Debug, and that the debug representation reads all parts of the value), but that might have more overhead and makes the MemorySanitizer trace more verbose because now the uninitialized read occurs deeply nested in the debug formatting code.

Footnotes

1. I assume the reason for this is that when the decompression function performs the invalid memory access it is copying data where source == target and then exposes that as result, so maybe MemorySanitizer does not consider copying uninitialized memory into uninitialized memory an error, respectively ignores when this occurs for source == target (so effectively a no-op). ↩

[hanna-kruppe]

This seems to me more about MemorySanitizer and how it interacts with rustc than about cargo-fuzz specifically. I'm not super familiar with MSan but the docs say it doesn't try to catch reads of uninit memory per se:

MSan is bit-exact: it can track uninitialized bits in a bitfield. It will tolerate copying of uninitialized memory, and also simple logic and arithmetic operations with it. In general, MSan silently tracks the spread of uninitialized data in memory, and reports a warning when:

• Uninitialized value was used in a conditional branch.
• Uninitialized pointer was used for memory accesses.
• Uninitialized value was passed or returned from a function call, which is considered an undefined behavior. The check can be disabled with -fno-sanitize-memory-param-retval.
• Uninitialized data was passed into some libc calls.

So if you want to use MSan to assert that specific region of memory is initialized, there doesn't seem to be a built-in way to do that, short of manually doing one of the things that MSan does try to detect with all data in that memory region. Tighter integration with Rust-specific rules like "when returning a Vec<u8>, the first len elements should be initialized" are of course right out. Not even miri does that! (both because miri doesn't know much about Vec specifically, and because carefully written unsafe code can do that without necessarily causing UB, so there's a risk of false alarms)

I guess printing the bytes works for your purpose because it ultimately passes uninit memory to the write() function, which MSan presumably has special handling for. I believe hint::black_box works in --dev because at opt-level=0 the compiler generates a regular function that accepts and then returns the uninitialized value. Enabling optimization makes rustc inline the black_box() call in your code before it even emits LLVM IR, so there's no call/return for MSan to instrument.

Depending on how well MSan tracks uninitialized bytes, maybe you could mix together all the bytes in question in a way that the compiler is unlikely to optimize out (e.g., sum or bitwise-xor them) and then print the single result value.

[Marcono1234]

Thanks for the reference to the MemorySanitizer wiki on the Google repository, that explains why it did not report copying of uninitialized data. I only had a look at the LLVM docs (assuming they were more up-to-date), but they did not mention these limitations.

Thanks also for the explanations! So it seems cargo-fuzz cannot really do something implementation-wise to improve this.
Maybe this issue here would then really be about extending the cargo-fuzz documentation to mention these limitations, as suggested in the issue description.