public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug sanitizer/97941] New: [HWASAN] use After free not working as per expectation
@ 2020-11-23  5:15 akhilesh.k at samsung dot com
  2020-11-23  8:19 ` [Bug sanitizer/97941] " marxin at gcc dot gnu.org
                   ` (2 more replies)
  0 siblings, 3 replies; 4+ messages in thread
From: akhilesh.k at samsung dot com @ 2020-11-23  5:15 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97941

            Bug ID: 97941
           Summary: [HWASAN] use After free not working as per expectation
           Product: gcc
           Version: 11.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: sanitizer
          Assignee: unassigned at gcc dot gnu.org
          Reporter: akhilesh.k at samsung dot com
                CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
                    jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at gcc dot gnu.org
  Target Milestone: ---

Hello Matthew

While HWASAN verification feature, Source I taken from GCC11 trunk. 
I observed Some HWASAN features are not working as per expectation. 
Like use After free, Is this known behaviors/Issue ? 



int main() {
  char *x = (char*)malloc(10 * sizeof(char*));
  free(x);
  return x[5];
} 

./myhak 
HWAddressSanitizer:DEADLYSIGNAL
==1227==ERROR: HWAddressSanitizer: SEGV on unknown address 0x000000000030 (pc
0x0000004096c8 bp 0x005f00ae9fe0 sp 0x005f00ae8d10 T1227)
==1227==The signal is caused by a UNKNOWN memory access.
==1227==Hint: address points to the zero page.
    #0 0x4096c8 in GetAccessInfo
/data2/2706/akhilesh.k/script/32/hwsetup/gcc-11.1.0/libsanitizer/hwasan/hwasan_linux.cpp:383
    #1 0x4096c8 in HwasanOnSIGTRAP
/data2/2706/akhilesh.k/script/32/hwsetup/gcc-11.1.0/libsanitizer/hwasan/hwasan_linux.cpp:445
    #2 0x4096c8 in __hwasan::HwasanOnDeadlySignal(int, void*, void*)
/data2/2706/akhilesh.k/script/32/hwsetup/gcc-11.1.0/libsanitizer/hwasan/hwasan_linux.cpp:470
    #3 0x5f00ae9fec  (<unknown module>)
    #4 0x406918 in __hwasan_load1
/data2/2706/akhilesh.k/script/32/hwsetup/gcc-11.1.0/libsanitizer/hwasan/hwasan.cpp:446
    #5 0x43815c in main
(/data10/1000/akhilesh.k/Activity/buildroot/myhak+0x43815c)
    #6 0x55009830a0 in __libc_start_main ../csu/libc-start.c:308
    #7 0x4023c4  (/data10/1000/akhilesh.k/Activity/buildroot/myhak+0x4023c4)

HWAddressSanitizer can not provide additional info.
SUMMARY: HWAddressSanitizer: SEGV
/data2/2706/akhilesh.k/script/32/hwsetup/gcc-11.1.0/libsanitizer/hwasan/hwasan_linux.cpp:383
in GetAccessInfo
==1227==ABORTING

^ permalink raw reply	[flat|nested] 4+ messages in thread

* [Bug sanitizer/97941] [HWASAN] use After free not working as per expectation
  2020-11-23  5:15 [Bug sanitizer/97941] New: [HWASAN] use After free not working as per expectation akhilesh.k at samsung dot com
@ 2020-11-23  8:19 ` marxin at gcc dot gnu.org
  2020-11-23 12:53 ` matmal01 at gcc dot gnu.org
  2020-12-11 11:39 ` matmal01 at gcc dot gnu.org
  2 siblings, 0 replies; 4+ messages in thread
From: marxin at gcc dot gnu.org @ 2020-11-23  8:19 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97941

Martin Liška <marxin at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2020-11-23
     Ever confirmed|0                           |1
                 CC|                            |matmal01 at gcc dot gnu.org
             Status|UNCONFIRMED                 |NEW

^ permalink raw reply	[flat|nested] 4+ messages in thread

* [Bug sanitizer/97941] [HWASAN] use After free not working as per expectation
  2020-11-23  5:15 [Bug sanitizer/97941] New: [HWASAN] use After free not working as per expectation akhilesh.k at samsung dot com
  2020-11-23  8:19 ` [Bug sanitizer/97941] " marxin at gcc dot gnu.org
@ 2020-11-23 12:53 ` matmal01 at gcc dot gnu.org
  2020-12-11 11:39 ` matmal01 at gcc dot gnu.org
  2 siblings, 0 replies; 4+ messages in thread
From: matmal01 at gcc dot gnu.org @ 2020-11-23 12:53 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97941

--- Comment #1 from Matthew Malcomson <matmal01 at gcc dot gnu.org> ---
Hi Akhilesh,

No that's certainly not a known issue -- thanks for reporting it!

I'm having trouble reproducing your issue, do you mind giving a little more
information on your command line and the machine you're running on etc?

One point that seems worth looking into is that the line numbers on your
backtrace don't seem to match up with the line numbers in my source tree.
(e.g. GetAccessInfo is given line number 383 of hwasan_linux.cpp, while in my
source tree that function spans lines 328-376).  Have you made any
modifications to the source?  Or maybe you're running a different libsanitizer
version?
For reference I'm using libsanitizer from LLVM hash
6e7dd1e3e1170080b76b5dcc5716bdd974343233, and the sha256sum of hwasan_linux.cpp
in my source tree is
3986e9f4e519409e7c73a7b97722125300afc4dc1f44a3f966fedf679329fd0a.

Based on what line number `HwasanOnSIGTRAP` calls `GetAccessInfo` in my source
tree, and assuming the offset between our line numbers are the same for the
GetAccessInfo line in your stack trace, it seems that the SEGV happens when
dereferencing the address that caused the signal.

That value should be the address of the `brk` instruction in __hwasan_load1
(having been inlined from `SigTrap` in hwasan_checks.h) which caught the bad
access, but the value of 0x30 which caused this SEGV is clearly not that value.

If the offset between our line numbers is a bit different, then getting that
address might make a bit more sense.  There are various struct member accesses
via pointers that `GetAccessInfo` recieves.
However, those arguments are just taken from the siginfo_t and ucontext_t
pointers that the kernel provides on receipt of a deadly signal.
I haven't found any access in that function which look like they would have an
offset of 0x30 from a NULL pointer, although I guess different kernel versions
would have different offsets.

What kernel are you running on?  Is there any chance the signal handler
HwasanOnDeadlySignal is getting a NULL pointer as one of its arguments?
For reference I happen to be running on a linux kernel based off of commit
585e5b17b9 (but with some modifications that should not affect anything -- just
config changes so I can build the kernel itself with -fsanitize=hwaddress).


Just for reference -- what I see when compiling your testcase:


ubuntu@ubuntu:~/working-directory/temp/pr97941$
../../gcc-hwasan-install/bin/gcc -fsanitize=hwaddress ./test.c -o test
./test.c: In function ‘main’:
./test.c:2:20: warning: implicit declaration of function ‘malloc’
[-Wimplicit-function-declaration]
    2 |   char *x = (char*)malloc(10 * sizeof(char*));
      |                    ^~~~~~
./test.c:1:1: note: include ‘<stdlib.h>’ or provide a declaration of ‘malloc’
  +++ |+#include <stdlib.h>
    1 | int main() {
./test.c:2:20: warning: incompatible implicit declaration of built-in function
‘malloc’ [-Wbuiltin-declaration-mismatch]
    2 |   char *x = (char*)malloc(10 * sizeof(char*));
      |                    ^~~~~~
./test.c:2:20: note: include ‘<stdlib.h>’ or provide a declaration of ‘malloc’
./test.c:3:3: warning: implicit declaration of function ‘free’
[-Wimplicit-function-declaration]
    3 |   free(x);
      |   ^~~~
./test.c:3:3: note: include ‘<stdlib.h>’ or provide a declaration of ‘free’
./test.c:3:3: warning: incompatible implicit declaration of built-in function
‘free’ [-Wbuiltin-declaration-mismatch]
./test.c:3:3: note: include ‘<stdlib.h>’ or provide a declaration of ‘free’
ubuntu@ubuntu:~/working-directory/temp/pr97941$
LD_LIBRARY_PATH=~/working-directory/gcc-hwasan-install/lib64 ./test
==8600==ERROR: HWAddressSanitizer: tag-mismatch on address 0xefe0ffff0005 at pc
0xffffa828be70
READ of size 1 at 0xefe0ffff0005 tags: e2/d5 (ptr/mem) in thread T0
    #0 0xffffa828be6c in SigTrap<0>
../../../../gcc-source/libsanitizer/hwasan/hwasan_checks.h:27
    #1 0xffffa828be6c in CheckAddress<(__hwasan::ErrorAction)0,
(__hwasan::AccessType)0, 0>
../../../../gcc-source/libsanitizer/hwasan/hwasan_checks.h:88
    #2 0xffffa828be6c in __hwasan_load1
../../../../gcc-source/libsanitizer/hwasan/hwasan.cpp:375
    #3 0x400944 in main
(/home/ubuntu/working-directory/temp/pr97941/test+0x400944)
    #4 0xffffa81598dc in __libc_start_main
(/lib/aarch64-linux-gnu/libc.so.6+0x1f8dc)

[0xefe0ffff0000,0xefe0ffff0060) is a small unallocated heap chunk; size: 96
offset: 5
0xefe0ffff0005 is located 5 bytes inside of 80-byte region
[0xefe0ffff0000,0xefe0ffff0050)
freed by thread T0 here:
    #0 0xffffa828d64c in __sanitizer_free
../../../../gcc-source/libsanitizer/hwasan/hwasan_interceptors.cpp:108
    #1 0x400934 in main
(/home/ubuntu/working-directory/temp/pr97941/test+0x400934)
    #2 0xffffa81598dc in __libc_start_main
(/lib/aarch64-linux-gnu/libc.so.6+0x1f8dc)
    #3 0x400814  (/home/ubuntu/working-directory/temp/pr97941/test+0x400814)

previously allocated here:
    #0 0xffffa828db30 in __sanitizer_malloc
../../../../gcc-source/libsanitizer/hwasan/hwasan_interceptors.cpp:169
    #1 0x400928 in main
(/home/ubuntu/working-directory/temp/pr97941/test+0x400928)
    #2 0xffffa81598dc in __libc_start_main
(/lib/aarch64-linux-gnu/libc.so.6+0x1f8dc)
    #3 0x400814  (/home/ubuntu/working-directory/temp/pr97941/test+0x400814)

hwasan_dev_note_heap_rb_distance: 1 1023
hwasan_dev_note_num_matching_addrs: 0
hwasan_dev_note_num_matching_addrs_4b: 0
Thread: T0 0xeffe00002000 stack: [0xffffccb69000,0xffffcd369000) sz: 8388608
tls: [0xffffa8bdc000,0xffffa8bdc760)
Memory tags around the buggy address (one tag corresponds to 16 bytes):
  0xfefd0fffef80: 00  00  00  00  00  00  00  00  00  00  00  00  00  00  00 
00 
  0xfefd0fffef90: 00  00  00  00  00  00  00  00  00  00  00  00  00  00  00 
00 
  0xfefd0fffefa0: 00  00  00  00  00  00  00  00  00  00  00  00  00  00  00 
00 
  0xfefd0fffefb0: 00  00  00  00  00  00  00  00  00  00  00  00  00  00  00 
00 
  0xfefd0fffefc0: 00  00  00  00  00  00  00  00  00  00  00  00  00  00  00 
00 
  0xfefd0fffefd0: 00  00  00  00  00  00  00  00  00  00  00  00  00  00  00 
00 
  0xfefd0fffefe0: 00  00  00  00  00  00  00  00  00  00  00  00  00  00  00 
00 
  0xfefd0fffeff0: 00  00  00  00  00  00  00  00  00  00  00  00  00  00  00 
00 
=>0xfefd0ffff000:[d5] d5  d5  d5  d5  00  00  00  00  00  00  00  00  00  00 
00 
  0xfefd0ffff010: 00  00  00  00  00  00  00  00  00  00  00  00  00  00  00 
00 
  0xfefd0ffff020: 00  00  00  00  00  00  00  00  00  00  00  00  00  00  00 
00 
  0xfefd0ffff030: 00  00  00  00  00  00  00  00  00  00  00  00  00  00  00 
00 
  0xfefd0ffff040: 00  00  00  00  00  00  00  00  00  00  00  00  00  00  00 
00 
  0xfefd0ffff050: 00  00  00  00  00  00  00  00  00  00  00  00  00  00  00 
00 
  0xfefd0ffff060: 00  00  00  00  00  00  00  00  00  00  00  00  00  00  00 
00 
  0xfefd0ffff070: 00  00  00  00  00  00  00  00  00  00  00  00  00  00  00 
00 
  0xfefd0ffff080: 00  00  00  00  00  00  00  00  00  00  00  00  00  00  00 
00 
Tags for short granules around the buggy address (one tag corresponds to 16
bytes):
  0xfefd0fffeff0: ..  ..  ..  ..  ..  ..  ..  ..  ..  ..  ..  ..  ..  ..  .. 
.. 
=>0xfefd0ffff000:[..] ..  ..  ..  ..  ..  ..  ..  ..  ..  ..  ..  ..  ..  .. 
.. 
  0xfefd0ffff010: ..  ..  ..  ..  ..  ..  ..  ..  ..  ..  ..  ..  ..  ..  .. 
.. 
See
https://clang.llvm.org/docs/HardwareAssistedAddressSanitizerDesign.html#short-granules
for a description of short granule tags
SUMMARY: HWAddressSanitizer: tag-mismatch
../../../../gcc-source/libsanitizer/hwasan/hwasan_checks.h:27 in SigTrap<0>

^ permalink raw reply	[flat|nested] 4+ messages in thread

* [Bug sanitizer/97941] [HWASAN] use After free not working as per expectation
  2020-11-23  5:15 [Bug sanitizer/97941] New: [HWASAN] use After free not working as per expectation akhilesh.k at samsung dot com
  2020-11-23  8:19 ` [Bug sanitizer/97941] " marxin at gcc dot gnu.org
  2020-11-23 12:53 ` matmal01 at gcc dot gnu.org
@ 2020-12-11 11:39 ` matmal01 at gcc dot gnu.org
  2 siblings, 0 replies; 4+ messages in thread
From: matmal01 at gcc dot gnu.org @ 2020-12-11 11:39 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97941

Matthew Malcomson <matmal01 at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |WORKSFORME
             Status|NEW                         |RESOLVED

--- Comment #2 from Matthew Malcomson <matmal01 at gcc dot gnu.org> ---
Resolving since this works for me and haven't any extra information to believe
that's a coincidence.

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2020-12-11 11:39 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-11-23  5:15 [Bug sanitizer/97941] New: [HWASAN] use After free not working as per expectation akhilesh.k at samsung dot com
2020-11-23  8:19 ` [Bug sanitizer/97941] " marxin at gcc dot gnu.org
2020-11-23 12:53 ` matmal01 at gcc dot gnu.org
2020-12-11 11:39 ` matmal01 at gcc dot gnu.org

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).