[libc] Fix read under msan

[michaelrj-google]

The read function wasn't properly unpoisoning its result under msan,
causing test failures downstream when I tried to roll it out. This patch
adds the msan unpoison call that fixes the issue.

[llvmbot]

@llvm/pr-subscribers-libc

Author: None (michaelrj-google)

Changes

The read function wasn't properly unpoisoning its result under msan,
causing test failures downstream when I tried to roll it out. This patch
adds the msan unpoison call that fixes the issue.

---

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

2 Files Affected:

• (modified) libc/src/unistd/linux/read.cpp (+5)
• (modified) utils/bazel/llvm-project-overlay/libc/BUILD.bazel (+1)

diff --git a/libc/src/unistd/linux/read.cpp b/libc/src/unistd/linux/read.cpp
index 691a236982e37..f5248a8547d44 100644
--- a/libc/src/unistd/linux/read.cpp
+++ b/libc/src/unistd/linux/read.cpp
@@ -11,6 +11,8 @@
 #include "src/__support/OSUtil/syscall.h" // For internal syscall function.
 #include "src/__support/common.h"
 
+#include "src/__support/macros/sanitizer.h" // for MSAN_UNPOISON
+
 #include "src/errno/libc_errno.h"
 #include <sys/syscall.h> // For syscall numbers.
 
@@ -22,6 +24,9 @@ LLVM_LIBC_FUNCTION(ssize_t, read, (int fd, void *buf, size_t count)) {
     libc_errno = static_cast<int>(-ret);
     return -1;
   }
+  // The cast is important since there is a check that dereferences the pointer
+  // which fails on void*.
+  MSAN_UNPOISON(reinterpret_cast<char *>(buf), count);
   return ret;
 }
 
diff --git a/utils/bazel/llvm-project-overlay/libc/BUILD.bazel b/utils/bazel/llvm-project-overlay/libc/BUILD.bazel
index 3b8ce044b7fc7..3d8c5eb178ec9 100644
--- a/utils/bazel/llvm-project-overlay/libc/BUILD.bazel
+++ b/utils/bazel/llvm-project-overlay/libc/BUILD.bazel
@@ -2599,6 +2599,7 @@ libc_function(
     hdrs = ["src/unistd/read.h"],
     deps = [
         ":__support_common",
+        ":__support_macros_sanitizer",
         ":__support_osutil_syscall",
         ":errno",
     ],

[nickdesaulniers]

cc @ramosian-glider @vitalybuka

I assume this is right, but perhaps Alexander or Vitaly know if this isn't (and why)?