Crash with addresssanitizer turned on

[chvp]

=================================================================
==382421==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7ffdecfdb74c at pc 0x00000046ff6b bp 0x7ffdecfdb100 sp 0x7ffdecfdb0f8
READ of size 1 at 0x7ffdecfdb74c thread T0
    #0 0x46ff6a in sdbm(unsigned char*, int) (/nix/store/hifyfd1liy26srm9nwc88z9g8fjj8vhp-udp2raw-20230206.0/bin/.udp2raw-wrapped+0x46ff6a)
    #1 0x583ee4 in std::__detail::_Map_base<address_t, std::pair<address_t const, unsigned int>, std::allocator<std::pair<address_t const, unsigned int> >, std::__detail::_Select1st, std::equal_to<address_t>, std::hash<address_t>, std::__detail::_Mod_range_hashing, std::__detail::_Default_ranged_hash, std::__detail::_Prime_rehash_policy, std::__detail::_Hashtable_traits<true, false, true>, true>::operator[](address_t const&) (/nix/store/hifyfd1liy26srm9nwc88z9g8fjj8vhp-udp2raw-20230206.0/bin/.udp2raw-wrapped+0x583ee4)
    #2 0x556104 in client_on_udp_recv(conn_info_t&) (/nix/store/hifyfd1liy26srm9nwc88z9g8fjj8vhp-udp2raw-20230206.0/bin/.udp2raw-wrapped+0x556104)
    #3 0x5cc9be in ev_invoke_pending (/nix/store/hifyfd1liy26srm9nwc88z9g8fjj8vhp-udp2raw-20230206.0/bin/.udp2raw-wrapped+0x5cc9be)
    #4 0x5e9531 in ev_run (/nix/store/hifyfd1liy26srm9nwc88z9g8fjj8vhp-udp2raw-20230206.0/bin/.udp2raw-wrapped+0x5e9531)
    #5 0x554d06 in client_event_loop() (/nix/store/hifyfd1liy26srm9nwc88z9g8fjj8vhp-udp2raw-20230206.0/bin/.udp2raw-wrapped+0x554d06)
    #6 0x419be2 in main (/nix/store/hifyfd1liy26srm9nwc88z9g8fjj8vhp-udp2raw-20230206.0/bin/.udp2raw-wrapped+0x419be2)
    #7 0x7ffa2fbe3acd in __libc_start_call_main (/nix/store/x33pcmpsiimxhip52mwxbb5y77dhmb21-glibc-2.37-8/lib/libc.so.6+0x23acd)
    #8 0x7ffa2fbe3b88 in __libc_start_main_alias_2 (/nix/store/x33pcmpsiimxhip52mwxbb5y77dhmb21-glibc-2.37-8/lib/libc.so.6+0x23b88)
    #9 0x41ba84 in _start (/nix/store/hifyfd1liy26srm9nwc88z9g8fjj8vhp-udp2raw-20230206.0/bin/.udp2raw-wrapped+0x41ba84)
Address 0x7ffdecfdb74c is located in stack of thread T0 at offset 1084 in frame
    #0 0x55559f in client_on_udp_recv(conn_info_t&) (/nix/store/hifyfd1liy26srm9nwc88z9g8fjj8vhp-udp2raw-20230206.0/bin/.udp2raw-wrapped+0x55559f)
  This frame has 32 object(s):
    [48, 52) 'udp_new_addr_len' (line 505)
    [64, 68) 'conv'
    [80, 84) 'conv' (line 501)
    [96, 100) 'key' (line 501)
    [112, 116) 'key' (line 501)
    [128, 136) '<unknown>'
    [160, 168) '<unknown>'
    [192, 200) '<unknown>'
    [224, 232) '<unknown>'
    [256, 264) '<unknown>'
    [288, 296) '<unknown>'
    [320, 328) '<unknown>'
    [352, 360) '<unknown>'
    [384, 392) '<unknown>'
    [416, 424) 'it'
    [448, 456) '<unknown>'
    [480, 488) '<unknown>'
    [512, 520) '<unknown>'
    [544, 552) '<unknown>'
    [576, 584) '__position' (line 501)
    [608, 616) '__ret'
    [640, 648) '<unknown>'
    [672, 688) 'tmp'
    [704, 720) '__guard'
    [736, 752) 'tmp'
    [768, 784) '__guard'
    [800, 828) 'udp_new_addr_in' (line 504)
    [864, 892) 'tmp_addr' (line 522)
    [928, 956) 'data' (line 501)
    [992, 1020) 'data' (line 501)
    [1056, 1084) 'data' (line 501) <== Memory access at offset 1084 overflows this variable
    [1120, 3320) 'buf' (line 503)
HINT: this may be a false positive if your program uses some custom stack unwind mechanism, swapcontext or vfork
      (longjmp and C++ exceptions *are* supported)
SUMMARY: AddressSanitizer: stack-buffer-overflow (/nix/store/hifyfd1liy26srm9nwc88z9g8fjj8vhp-udp2raw-20230206.0/bin/.udp2raw-wrapped+0x46ff6a) in sdbm(unsigned char*, int)
Shadow bytes around the buggy address:
  0x10003d9f3690: f2 f2 00 f2 f2 f2 00 f2 f2 f2 00 f2 f2 f2 00 f2
  0x10003d9f36a0: f2 f2 00 f2 f2 f2 00 f2 f2 f2 00 f2 f2 f2 00 f2
  0x10003d9f36b0: f2 f2 00 f2 f2 f2 00 00 f2 f2 00 00 f2 f2 00 00
  0x10003d9f36c0: f2 f2 00 00 f2 f2 00 00 00 04 f2 f2 f2 f2 00 00
  0x10003d9f36d0: 00 04 f2 f2 f2 f2 00 00 00 04 f2 f2 f2 f2 00 00
=>0x10003d9f36e0: 00 04 f2 f2 f2 f2 00 00 00[04]f2 f2 f2 f2 00 00
  0x10003d9f36f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10003d9f3700: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10003d9f3710: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10003d9f3720: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10003d9f3730: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
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
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  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
==382421==ABORTING

[wangyu-]

Could you provide the parameters for client and server?

[chvp]

Client-side: udp2raw -c -l 127.0.0.1:51820 -r <server ipv4 address>:8080 -k <long alphanumeric string> Server-side: udp2raw -s -l 0.0.0.0:8080 -r 127.0.0.1:51820 -k <same long alphanumeric string>

[wangyu-]

sorry, I have been super busy in the past month. But I will look into the problem this weekend.

I tried the fix in https://github.com/wangyu-/UDPspeeder/pull/314, but unfortunately it doesn't work as expected.

by the way how easy is it to reproduce this problem? does it happen immediately/reliably if you send some data over the tunnel?

If not happen immediately/reliably, do you have a good way to reproduce this problem easily?

[chvp]

Yeah, it happens immediately on startup, every time.

[wangyu-]

this is fixed in https://github.com/wangyu-/udp2raw/commit/e66eddd1d554c12a52497476fb79efde112de576

[wangyu-]

By the way there are some memory leak detected by the sanitizer, after udp2raw is killed by CTRL-c

They might be false postive, since I am using self-written grabage collectors to collect inactive connections. When killed-by CTRL-c, some resource may not have been collected yet. (I will do further confirm when I am free)