Fix out of bounds write in ReadRemoteData

chrome/browser/conflicts/module_event_sink_impl_win.cc

Index: chrome/browser/conflicts/module_event_sink_impl_win.cc
diff --git a/chrome/browser/conflicts/module_event_sink_impl_win.cc b/chrome/browser/conflicts/module_event_sink_impl_win.cc
index d58475bab49427b6b1a8fc64e49d2c98e2e6dfd2..e7918b8e7ca0bf1e98b1eb08d4b7fb48e17a4533 100644
--- a/chrome/browser/conflicts/module_event_sink_impl_win.cc
+++ b/chrome/browser/conflicts/module_event_sink_impl_win.cc
@@ -64,11 +64,11 @@ bool ReadRemoteData(base::ProcessHandle process, uint64_t address, T* data) {
   const void* typed_address =
       reinterpret_cast<const void*>(static_cast<uintptr_t>(address));
   SIZE_T bytes_read = 0;
-  if (!::ReadProcessMemory(process, typed_address, data, sizeof(data),
+  if (!::ReadProcessMemory(process, typed_address, data, sizeof(*data),

[chrisha, 2017/02/15 21:23:42]

Pointers are hard /facepalm

Thanks for catching this. Surprised this didn't catch on a sanitizer bot?

[Nico, 2017/02/15 21:47:58]

Do we have 64-bit sanitizer bots? The clang/asan runtime at least isn't quite
ready on 64-bit yet.

Also, at least clang/asan works by emitting instrumented code and
ReadProcessMemory is a system function and hence not instrumented.

Having said that, I found this 'cause it did break our clang/win 64-bit dbg bot,
so it was caught by some bot. A 64-bit debug msvc bot would've probably caught
this as well, but as far as I know we don't have one.

                            &bytes_read)) {
     return false;
   }
-  if (bytes_read != sizeof(data))
+  if (bytes_read != sizeof(*data))
     return false;
   return true;
 }