[Live-devel] Invalid read in HandleCmd_DESCRIBE

Meng Ruijie ruijie_meng at u.nus.edu
Thu Jun 8 04:24:24 PDT 2023


We used the address sanitizer to reproduce this bug again. The following is the bug report. We also attached the relevant files, and you can reproduce this bug based on the README.

=================================================================
==3853==ERROR: AddressSanitizer: stack-use-after-return on address 0x7ffff32ec3d0 at pc 0x7ffff762ddcb bp 0x7fffffffc640 sp 0x7fffffffbdb8
READ of size 2 at 0x7ffff32ec3d0 thread T0
    #0 0x7ffff762ddca in printf_common ../../../../src/libsanitizer/sanitizer_common/sanitizer_common_interceptors_format.inc:546
    #1 0x7ffff7630ad5 in __interceptor_vsnprintf ../../../../src/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:1608
    #2 0x7ffff7631046 in __interceptor___snprintf_chk ../../../../src/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:1684
    #3 0x555555cb5658 in snprintf /usr/include/x86_64-linux-gnu/bits/stdio2.h:67
    #4 0x555555cb5658 in RTSPServer::RTSPClientConnection::handleCmd_DESCRIBE_afterLookup(ServerMediaSession*) /home/ubuntu/experiments/live/liveMedia/RTSPServer.cpp:434
    #5 0x555555ca3440 in RTSPServer::RTSPClientConnection::handleCmd_DESCRIBE(char const*, char const*, char const*) /home/ubuntu/experiments/live/liveMedia/RTSPServer.cpp:397
    #6 0x555555ca7106 in RTSPServer::RTSPClientConnection::handleRequestBytes(int) /home/ubuntu/experiments/live/liveMedia/RTSPServer.cpp:862
    #7 0x555555fb938f in GenericMediaServer::ClientConnection::incomingRequestHandler() /home/ubuntu/experiments/live/liveMedia/GenericMediaServer.cpp:324
    #8 0x5555560c61b2 in BasicTaskScheduler::SingleStep(unsigned int) /home/ubuntu/experiments/live/BasicUsageEnvironment/BasicTaskScheduler.cpp:171
    #9 0x5555560daf33 in BasicTaskScheduler0::doEventLoop(char volatile*) /home/ubuntu/experiments/live/BasicUsageEnvironment/BasicTaskScheduler0.cpp:82
    #10 0x555555c82f67 in main /home/ubuntu/experiments/live/testProgs/testOnDemandRTSPServer.cpp:462
    #11 0x7ffff639f082 in __libc_start_main ../csu/libc-start.c:308
    #12 0x555555c87ead in _start (/home/ubuntu/experiments/live/testProgs/testOnDemandRTSPServer+0x733ead)

Address 0x7ffff32ec3d0 is located in stack of thread T0 at offset 976 in frame
    #0 0x555555ca366f in RTSPServer::RTSPClientConnection::handleRequestBytes(int) /home/ubuntu/experiments/live/liveMedia/RTSPServer.cpp:699

  This frame has 14 object(s):
    [48, 49) 'urlIsRTSPS' (line 794)
    [64, 65) 'reuseConnection' (line 914)
    [80, 81) 'deliverViaTCP' (line 914)
    [96, 100) 'decodedSize' (line 743)
    [112, 116) 'contentLength' (line 793)
    [128, 136) 'proxyURLSuffix' (line 915)
    [160, 360) 'cmdName' (line 788)
    [432, 632) 'urlPreSuffix' (line 789)
    [704, 904) 'urlSuffix' (line 790)
    [976, 1176) 'cseq' (line 791) <== Memory access at offset 976 is inside this variable
    [1248, 1448) 'sessionIdStr' (line 792)
    [1520, 1720) 'sessionCookie' (line 933)
    [1792, 1992) 'acceptStr' (line 934)
    [2064, 2464) 'urlTotalSuffix' (line 871)
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-use-after-return ../../../../src/libsanitizer/sanitizer_common/sanitizer_common_interceptors_format.inc:546 in printf_common
Shadow bytes around the buggy address:
  0x10007e655820: f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5
  0x10007e655830: f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5
  0x10007e655840: f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5
  0x10007e655850: f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5
  0x10007e655860: f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5
=>0x10007e655870: f5 f5 f5 f5 f5 f5 f5 f5 f5 f5[f5]f5 f5 f5 f5 f5
  0x10007e655880: f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5
  0x10007e655890: f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5
  0x10007e6558a0: f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5
  0x10007e6558b0: f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5
  0x10007e6558c0: 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
  Shadow gap:              cc
==3853==ABORTING


------
Kind Regards,
Ruijie
________________________________
From: live-devel <live-devel-bounces at us.live555.com> on behalf of Ross Finlayson <finlayson at live555.com>
Sent: Thursday, June 8, 2023 16:34
To: LIVE555 Streaming Media - development & use <live-devel at us.live555.com>
Subject: Re: [Live-devel] Invalid read in HandleCmd_DESCRIBE

        - External Email -



> On Jun 8, 2023, at 5:08 PM, Meng Ruijie <ruijie_meng at u.nus.edu> wrote:
>
> Hi,
>
> We found one memory issue

No you didn’t.  You ran “valgrind”, and it said that there was an “invalid read”.  But you didn’t find out whether or not this report was real (“valgrind” is often mistaken), and, even if it is real, what, specifically, in our code is a problem.

Once again, running “valgrind” and having it claim that there is a problem is not the same as “finding” a problem.


Ross Finlayson
Live Networks, Inc.
http://www.live555.com/


_______________________________________________
live-devel mailing list
live-devel at lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20230608/a2bbd4ea/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: use-after-return.tar.gz
Type: application/gzip
Size: 2591827 bytes
Desc: use-after-return.tar.gz
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20230608/a2bbd4ea/attachment-0001.bin>


More information about the live-devel mailing list