-
Notifications
You must be signed in to change notification settings - Fork 13.8k
Description
Code
This comes from oss-fuzz cf https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=55286&q=label%3AProj-suricata
This is with RUSTFLAGS='--cfg fuzzing -Zsanitizer=memory -Cdebuginfo=1 -Cforce-frame-pointers -Zsanitizer-memory-track-origins'
It happens with C code calling a rust function which returns std::ptr::null_mut()
, and then C code checks the pointer for NULL
Basically, it reports use of uninitialized value at
https://github.com/OISF/suricata/blob/a24d7dc45c818054f97448ce42ca9ba270b3b8e4/src/detect-dce-iface.c#L151
void *did = rs_dcerpc_iface_parse(arg);
if (did == NULL) {
And rs_dcerpc_iface_parse
is returning std::ptr::null_mut()
cf https://github.com/OISF/suricata/blob/a24d7dc45c818054f97448ce42ca9ba270b3b8e4/rust/src/dcerpc/detect.rs#L243
I expected to see this happen: no report from Memory sanitizer
Instead, this happened:
==13==WARNING: MemorySanitizer: use-of-uninitialized-value
#0 0xe25448 in DetectDceIfaceSetup /src/suricata/src/detect-dce-iface.c:151:9
Version it worked on
It most recently worked on: nightly-2023-01-17
Version with regression
rustc --version --verbose
:
Sorry it is nightly-2023-01-18
rustc --version --verbose
rustc 1.68.0-nightly (3984bc583 2023-01-17)
binary: rustc
commit-hash: 3984bc5833db8bfb0acc522c9775383e4171f3de
commit-date: 2023-01-17
host: x86_64-unknown-linux-gnu
release: 1.68.0-nightly
LLVM version: 15.0.6
Activity
catenacyber commentedon Jan 21, 2023
And it worked on
rustup default nightly-2023-01-17
tmiasko commentedon Jan 21, 2023
That looks like noundef mismatch between C and Rust on return value due to #106294. Building Rust with
-Cllvm-args=-msan-eager-checks=0
might help (and-fnosanitize-memory-param-retval
in clang), but ultimately this probably requires clang with llvm/llvm-project@166c8cc.suricata: fix rust+C MSAN build
catenacyber commentedon Jan 21, 2023
Thank you very much @tmiasko
-Cllvm-args=-msan-eager-checks=0
does the trick cf google/oss-fuzz#9478C is compiled with
suricata: fix rust+C MSAN build (#9478)
elichai commentedon Jan 22, 2023
We encountered this in: rust-bitcoin/rust-secp256k1#573
And was just about to open an issue with this Minimal Reproducible Example: (a few lines of code) https://github.com/elichai/msan_c_rust_bug
but it sounds like this is a bug coming from mismatching llvm definitions?
to_hex
function rust-bitcoin/rust-secp256k1#573Overcome ASAN false positive regression
Overcome ASAN false positive regression
1 remaining item
Merge #574: Overcome ASAN false positive regression
apiraino commentedon Jan 25, 2023
WG-prioritization assigning priority (Zulip discussion).
@rustbot label -I-prioritize +P-high
RalfJung commentedon Jan 27, 2023
Having
noundef
on the definition but not the declaration (or vice versa) should be totally fine if the return value is indeed alwaysnoundef
. So I am surprised that the sanitizer complains here, how would the presence of the attribute (without a change in behavior) make any difference?suricata: fix rust+C MSAN build (google#9478)
catenacyber commentedon Mar 31, 2023
Looks like there was another regression between
rustc 1.70.0-nightly (8be3c2bda 2023-03-24)
andrustc 1.70.0-nightly (0c61c7a97 2023-03-25)
I now see
Is this the same issue or another one ?
tmiasko commentedon Mar 31, 2023
Mismatch in LLVM version between clang and rustc? Rust was upgraded to LLVM 16 in #109474. Also, clang 16 enabled sanitize-memory-param-retval, which matches rustc defaults now.
catenacyber commentedon Apr 3, 2023
Thanks @tmiasko :-)
Suricata rust clang16 (#10019)
pnkfelix commentedon Jun 30, 2023
Do any of the other participants have a response to @RalfJung 's point here? It definitely seems odd.
wesleywiser commentedon Nov 17, 2023
If I'm reading this issue correctly, we have a msan instrumented C program compiled with clang 15 and a msan instrumented Rust binary compiled with Rust/LLVM 16. I believe in order for sanitizers in general to work correctly, all of the instrumented objects in your program need to be compiled against the same version of the sanitizer runtime.
Since this is somewhat expected as the sanitizer versions do not match, I'm going to close this issue.