Re: libsanitizer: Hwasan reporting check for dladdr failing

[Matthew Malcomson via Gcc-patches]

On 24/11/2020 15:53, Kyrylo Tkachov wrote:
Hi Matthew,
-----Original Message-----
From: Gcc-patches <gcc-patches-boun...@gcc.gnu.org> On Behalf Of
Matthew Malcomson via Gcc-patches
Sent: 24 November 2020 15:47
To: gcc-patches@gcc.gnu.org
Cc: Richard Sandiford <richard.sandif...@arm.com>
Subject: libsanitizer: Hwasan reporting check for dladdr failing

Hello there,

This is the compiler-rt patch I'd like to cherry-pick so that the hwasan tests
pass.

It is in LLVM as commit 83ac18205ec69a00ac2be3b603bc3a61293fbe89.

Ok for trunk?

Also is the libhwasan library merge from the below email OK for trunk?
https://gcc.gnu.org/pipermail/gcc-patches/2020-November/558999.html
(Note I would also add a line to README.gcc mentioning compiler-
rt/lib/hwasan
on top of the changes in that patch).

I would guess so, but wasn't certain the OK had ever been said anywhere.

I believe merges from an upstream are generally considered pre-approved. In any 
case, I see that merge committed as 98f792ff538109c71d85ab2a61461cd090f3b9f3

Thanks,
Kyrill

Thanks Kyrill,

For the record, 98f792ff538109c71d85ab2a61461cd090f3b9f3 is the merge 
without libhwasan part, while I was asking about the libhwasan part.

However, given the standard pre-approved merge from upstream status I 
guess it doesn't matter -- and that's good to know for the future too.

Thanks!
Matthew



Regards,
Matthew

-------------------------


In `GetGlobalSizeFromDescriptor` we use `dladdr` to get info on the the
current address.  `dladdr` returns 0 if it failed.
During testing on Linux this returned 0 to indicate failure, and
populated the `info` structure with a NULL pointer which was
dereferenced later.

This patch checks for `dladdr` returning 0, and in that case returns 0
from `GetGlobalSizeFromDescriptor` to indicate failure of identifying
the address.

This occurs when `GetModuleNameAndOffsetForPC` succeeds for some
address
not in a dynamically loaded library.  One example is when the found
"module" is '[stack]' having come from parsing /proc/self/maps.

Cherry-pick from 83ac18205ec69a00ac2be3b603bc3a61293fbe89.

Differential Revision: https://reviews.llvm.org/D91344


###############     Attachment also inlined for ease of reply
###############


diff --git a/libsanitizer/hwasan/hwasan_report.cpp
b/libsanitizer/hwasan/hwasan_report.cpp
index
0be7deeaee1a0bd523d9e0fe1dc3b1311b3920e2..894a149775f291bae9cad8
33b1ac54914212f405 100644
--- a/libsanitizer/hwasan/hwasan_report.cpp
+++ b/libsanitizer/hwasan/hwasan_report.cpp
@@ -254,7 +254,8 @@ static bool TagsEqual(tag_t tag, tag_t *tag_ptr) {
  static uptr GetGlobalSizeFromDescriptor(uptr ptr) {
    // Find the ELF object that this global resides in.
    Dl_info info;
-  dladdr(reinterpret_cast<void *>(ptr), &info);
+  if (dladdr(reinterpret_cast<void *>(ptr), &info) == 0)
+    return 0;
    auto *ehdr = reinterpret_cast<const ElfW(Ehdr) *>(info.dli_fbase);
    auto *phdr_begin = reinterpret_cast<const ElfW(Phdr) *>(
        reinterpret_cast<const u8 *>(ehdr) + ehdr->e_phoff);