ohnx / minervabot

Modular IRC bot. The reincarnation of athenabot!
Apache License 2.0
2 stars 1 forks source link

fix issue with hashmap #4

Closed ohnx closed 5 years ago

ohnx commented 6 years ago

it apparently corrupts the heap and the stack???

ohnx commented 6 years ago

ok this is weird... somehow the hashmap address changes??

ohnx commented 6 years ago

before:

map locationL: 0x60300000efe0

after:

map locationL: 0x60300000ef00
==17278==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60300000ef10 at pc 0x7fac736796d4 bp 0x7fffc33e8db0 sp 0x7fffc33e8da8
READ of size 8 at 0x60300000ef10 thread T0
    #0 0x7fac736796d3 in hashmap_get src/hashmap.c:147
    #1 0x7fac7367a5ce in permissions_get src/permissions.c:33
    #2 0x7fac6e8fdde9 in handle_cmd src/modules/bot_perms.c:20
    #3 0x7fac736781c1 in modules_check_cmd src/modules.c:131
    #4 0x7fac7367b91b in irc_loop src/irc.c:146
    #5 0x7fac7367aa31 in main src/main.c:72
    #6 0x7fac71f312b0 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x202b0)
    #7 0x7fac73677af9 in _start (/home/c9/workspace/minervabot/minervabot+0x2af9)

0x60300000ef10 is located 10 bytes to the right of 22-byte region [0x60300000eef0,0x60300000ef06)
allocated by thread T0 here:
    #0 0x7fac72575d28 in malloc (/usr/lib/x86_64-linux-gnu/libasan.so.3+0xc1d28)
    #1 0x7fac7201961e in __nss_database_lookup (/lib/x86_64-linux-gnu/libc.so.6+0x10861e)

SUMMARY: AddressSanitizer: heap-buffer-overflow src/hashmap.c:147 in hashmap_get
Shadow bytes around the buggy address:
  0x0c067fff9d90: fd fd fd fa fa fa 00 00 00 04 fa fa 00 00 00 04
  0x0c067fff9da0: fa fa 00 00 00 fa fa fa 00 00 00 00 fa fa 00 00
  0x0c067fff9db0: 00 fa fa fa 00 00 00 00 fa fa 00 00 00 01 fa fa
  0x0c067fff9dc0: 00 00 04 fa fa fa 00 00 07 fa fa fa 00 00 00 01
  0x0c067fff9dd0: fa fa 00 00 00 02 fa fa 00 00 00 01 fa fa 00 00
=>0x0c067fff9de0: 06 fa[fa]fa 00 00 00 fa fa fa 00 00 07 fa fa fa
  0x0c067fff9df0: 00 00 06 fa fa fa 00 00 07 fa fa fa 00 00 00 fa
  0x0c067fff9e00: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c067fff9e10: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c067fff9e20: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c067fff9e30: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:       fa
  Heap right redzone:      fb
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack partial redzone:   f4
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb
==17278==ABORTING
ohnx commented 6 years ago

ok so somehow, the variable perm_map or whatever other global values are stored in permissions.c get changed from 0x60300000efe0 to 0x60300000ef00... wtf???

ohnx commented 6 years ago

this is partially closed using a workaround, but I still haven't found the root cause of the problem.

ohnx commented 5 years ago

This issue no longer manifests itself and I have no idea what caused it to begin with. I'll chalk it down to magic and move on.