Buffer overlow when launching GPAC multicast gateway

[TuanTranBPK]

The issue happens in both unicast repair config activated/deactivated in GPAC multicast gateway. On server, it also happens whether low-latency is enabled or not. Stream E is used to deliver in multicast.

Please see attached for all possible logs as well as pcap capture from multicast server.
buffer_overflow.zip

[rbouqueau]

I can't reproduce:

$ ./app.py /tmp/tmp/buffer_overflow/server_config.ini 
WARNING: this python wrapper is for GPAC ABI 12.14 but native libgpac ABI is 12.15
        Undefined behavior or crashes might happen, please update libgpac.py
[DVB-FLUTE] IP audio_dash_track1_init.mp4 is not a multicast address
Filter routeout failed to setup: Bad Parameter
[Dasher] Couldn't create output file audio_dash_track1_init.mp4: Bad Parameter
[DVB-FLUTE] IP video_dash_track2_init.mp4 is not a multicast address
Filter routeout failed to setup: Bad Parameter
[Dasher] Couldn't create output file video_dash_track2_init.mp4: Bad Parameter
Attempt to allocate a packet on a NULL PID

[rbouqueau]

Neither @soheibthriber nor myself can reproduce. Which platforms are you on? Maybe we should organize a short call to make sure we replicate this.

[soheibthriber]

DASH to be deleted @sla] Buffer overflow causing string: https://akamaibroadcasteruseast.akamaized.net/cmaf/live/657078/akasource/1721610001/chunk-stream_1- size: 99 
=================================================================
==13846==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7fffd8b5e5d4 at pc 0x7ffff78f94d3 bp 0x7fffffffc2e0 sp 0x7fffffffba88
WRITE of size 2 at 0x7fffd8b5e5d4 thread T0
    #0 0x7ffff78f94d2 in memcpy ../../../../src/libsanitizer/sanitizer_common/sanitizer_common_interceptors_memintrinsics.inc:115
    #1 0x7ffff0aae97d in gf_dash_group_timeline_setup_single media_tools/dash_client.c:856
    #2 0x7ffff0ac32d2 in gf_dash_group_timeline_setup media_tools/dash_client.c:1488
    #3 0x7ffff0aeb972 in gf_dash_resolve_url media_tools/dash_client.c:3497
    #4 0x7ffff0b068fa in gf_dash_download_init_segment media_tools/dash_client.c:4891
    #5 0x7ffff0b4d860 in dash_setup_period_and_groups media_tools/dash_client.c:7854
    #6 0x7ffff0b532c7 in gf_dash_process_internal media_tools/dash_client.c:8159
    #7 0x7ffff0b5442a in gf_dash_process media_tools/dash_client.c:8230
    #8 0x7ffff1953ef4 in dashdmx_process filters/dmx_dash.c:3237
    #9 0x7ffff168a49c in gf_filter_process_task filter_core/filter.c:3171
    #10 0x7ffff1626955 in gf_fs_thread_proc filter_core/filter_session.c:2171
    #11 0x7ffff162a46b in gf_fs_run filter_core/filter_session.c:2478
    #12 0x55555556204f in gpac_main /home/sohaib/gpac/gpac_public/applications/gpac/gpac.c:1598
    #13 0x555555562484 in main /home/sohaib/gpac/gpac_public/applications/gpac/gpac.c:1854
    #14 0x7fffeb22a1c9 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
    #15 0x7fffeb22a28a in __libc_start_main_impl ../csu/libc-start.c:360
    #16 0x55555555d314 in _start (/home/sohaib/gpac/gpac_public/bin/gcc/gpac+0x9314) (BuildId: a2ccdb6707fa9d1833bff7f1275b9b173982460a)

Address 0x7fffd8b5e5d4 is located in stack of thread T0 at offset 468 in frame
    #0 0x7ffff0aa8bb1 in gf_dash_group_timeline_setup_single media_tools/dash_client.c:621

  This frame has 11 object(s):
    [32, 36) 'tpl_use_time' (line 832)
    [48, 56) 'sr' (line 805)
    [80, 88) 'seg_dur_ms' (line 805)
    [112, 120) 'seg_url' (line 808)
    [144, 152) 'number' (line 849)
    [176, 184) 'utc' (line 992)
    [208, 216) 'utc' (line 1048)
    [240, 248) 'gtime1' (line 1098)
    [272, 280) 'gtime2' (line 1098)
    [304, 324) 'szFmt' (line 858)
    [368, 468) 'szTemplate' (line 850) <== Memory access at offset 468 overflows this variable
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 ../../../../src/libsanitizer/sanitizer_common/sanitizer_common_interceptors_memintrinsics.inc:115 in memcpy
Shadow bytes around the buggy address:
  0x7fffd8b5e300: f3 f3 f3 f3 00 00 00 00 00 00 00 00 00 00 00 00
  0x7fffd8b5e380: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x7fffd8b5e400: f1 f1 f1 f1 04 f2 00 f2 f2 f2 00 f2 f2 f2 00 f2
  0x7fffd8b5e480: f2 f2 00 f2 f2 f2 00 f2 f2 f2 00 f2 f2 f2 00 f2
  0x7fffd8b5e500: f2 f2 00 f2 f2 f2 00 00 04 f2 f2 f2 f2 f2 00 00
=>0x7fffd8b5e580: 00 00 00 00 00 00 00 00 00 00[04]f3 f3 f3 f3 f3
  0x7fffd8b5e600: f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5
  0x7fffd8b5e680: f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5
  0x7fffd8b5e700: f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 00 00 00 00
  0x7fffd8b5e780: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x7fffd8b5e800: f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5
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
==13846==ABORTING
[1] + Done                       "/usr/bin/gdb" --interpreter=mi --tty=${DbgTerm} 0<"/tmp/Microsoft-MIEngine-In-vzvlyp3p.y2k" 1>"/tmp/Microsoft-MIEngine-Out-tdeh4xl1.dse"

I did reproduce and i think the buffer overflow is produced because of a static declaration of the szTemplate variable in dash_client.c. i will propose a modification in gpac code

[soheibthriber]

fix proposed in this pull request: gpac/gpac#2940

If we can test (i tested from my end) , than merge i think we can close this issue.

[rbouqueau]

The PR was merge. Can someone test it is gone please?