[libfuzzer] Prevent MSan false positive when printing log with -jobs

[thurstond]

libfuzzer's -jobs option will, depending on the number of CPUs, spin up a
WorkerThread and end up printing the log file using CopyFileToErr.
This leads to an MSan false positive. This patch disables the MSan interceptor checks,
similarly to other instances in https://reviews.llvm.org/D48891

Side-note: this false positive issue first appeared when printf()
was replaced by puts() (90b4d1b).
The interceptor check was always present; however, MSan does not
check_printf by default.

[llvmbot]

@llvm/pr-subscribers-compiler-rt-sanitizer

Author: Thurston Dang (thurstond)

Changes

The -jobs option will, depending on the number of CPUs, spin up a
WorkerThread and end up printing the log file using CopyFileToErr.
This leads to an MSan false positive. This patch disables the MSan interceptor checks,
similarly to other instances in https://reviews.llvm.org/D48891

Side-note: this false positive issue first appeared when printf()
was replaced by puts() (90b4d1b).
The interceptor check was always present; however, MSan does not
check_printf by default.

---

Full diff: https://github.com/llvm/llvm-project/pull/91679.diff

1 Files Affected:

• (modified) compiler-rt/lib/fuzzer/FuzzerIO.cpp (+2)

diff --git a/compiler-rt/lib/fuzzer/FuzzerIO.cpp b/compiler-rt/lib/fuzzer/FuzzerIO.cpp
index 54cc4ee54be0a..9e9a93a0a48da 100644
--- a/compiler-rt/lib/fuzzer/FuzzerIO.cpp
+++ b/compiler-rt/lib/fuzzer/FuzzerIO.cpp
@@ -10,6 +10,7 @@
 
 #include "FuzzerDefs.h"
 #include "FuzzerExtFunctions.h"
+#include "FuzzerInternal.h"
 #include "FuzzerIO.h"
 #include "FuzzerUtil.h"
 #include <algorithm>
@@ -65,6 +66,7 @@ std::string FileToString(const std::string &Path) {
 }
 
 void CopyFileToErr(const std::string &Path) {
+  ScopedDisableMsanInterceptorChecks S;
   Puts(FileToString(Path).c_str());
 }
 

[github-actions]

✅ With the latest revision this PR passed the C/C++ code formatter.

[eugenis]

This looks reasonable, but I wonder if it would be safer to move the scoped-disable thing to the start of WorkerThread? The thread does not run any user code, so we never want any interceptor checks (and it may run some other interceptors, like fork/exec, mutex stuff, etc).

[jonathanmetzman]

lgtm

[thurstond]

This looks reasonable, but I wonder if it would be safer to move the scoped-disable thing to the start of WorkerThread? The thread does not run any user code, so we never want any interceptor checks (and it may run some other interceptors, like fork/exec, mutex stuff, etc).

Done, thanks for the review!