Wireshark mailing list archives

Can ASAN be somehow tweaked to symbolicate its stack traces?


From: Guy Harris <guy () alum mit edu>
Date: Fri, 5 Feb 2016 16:38:17 -0800

On Feb 5, 2016, at 1:30 PM, bugzilla-daemon () wireshark org wrote:

Bug ID        12087
Summary       Buildbot crash output: fuzz-2016-02-05-5267.pcap
Product       Wireshark
Version       unspecified
Hardware      x86-64
URL   https://www.wireshark.org/download/automated/captures/fuzz-2016-02-05-5267.pcap
OS    Ubuntu

        ...

Problems have been found with the following capture file:

        ...

=================================================================
==2982==ERROR: AddressSanitizer: global-buffer-overflow on address
0x7f7fa3c48494 at pc 0x7f7fa1f3ee1e bp 0x7ffc28499600 sp 0x7ffc284995f8
READ of size 4 at 0x7f7fa3c48494 thread T0
    #0 0x7f7fa1f3ee1d 
(/home/wireshark/builders/wireshark-master-fuzz/clangcodeanalysis/install/lib/libwireshark.so.0+0x7985e1d)
    #1 0x7f7fa18da2e1 
(/home/wireshark/builders/wireshark-master-fuzz/clangcodeanalysis/install/lib/libwireshark.so.0+0x73212e1)
    #2 0x7f7fa18d83bc 
(/home/wireshark/builders/wireshark-master-fuzz/clangcodeanalysis/install/lib/libwireshark.so.0+0x731f3bc)
    #3 0x7f7fa22a7136 
(/home/wireshark/builders/wireshark-master-fuzz/clangcodeanalysis/install/lib/libwireshark.so.0+0x7cee136)
    #4 0x7f7fa18da2e1 
(/home/wireshark/builders/wireshark-master-fuzz/clangcodeanalysis/install/lib/libwireshark.so.0+0x73212e1)
    #5 0x7f7fa18d9f7a 
(/home/wireshark/builders/wireshark-master-fuzz/clangcodeanalysis/install/lib/libwireshark.so.0+0x7320f7a)
    #6 0x7f7fa1e0dd15 
(/home/wireshark/builders/wireshark-master-fuzz/clangcodeanalysis/install/lib/libwireshark.so.0+0x7854d15)
    #7 0x7f7fa18da2e1 
(/home/wireshark/builders/wireshark-master-fuzz/clangcodeanalysis/install/lib/libwireshark.so.0+0x73212e1)
    #8 0x7f7fa18d83bc 
(/home/wireshark/builders/wireshark-master-fuzz/clangcodeanalysis/install/lib/libwireshark.so.0+0x731f3bc)
    #9 0x7f7fa18d7bd8 
(/home/wireshark/builders/wireshark-master-fuzz/clangcodeanalysis/install/lib/libwireshark.so.0+0x731ebd8)
    #10 0x7f7fa18b833e 
(/home/wireshark/builders/wireshark-master-fuzz/clangcodeanalysis/install/lib/libwireshark.so.0+0x72ff33e)
    #11 0x501145 
(/home/wireshark/builders/wireshark-master-fuzz/clangcodeanalysis/install/bin/tshark+0x501145)
    #12 0x4fb96b 
(/home/wireshark/builders/wireshark-master-fuzz/clangcodeanalysis/install/bin/tshark+0x4fb96b)
    #13 0x7f7f971f7ec4  (/lib/x86_64-linux-gnu/libc.so.6+0x21ec4)
    #14 0x43fc26 
(/home/wireshark/builders/wireshark-master-fuzz/clangcodeanalysis/install/bin/tshark+0x43fc26)

0x7f7fa3c48494 is located 12 bytes to the left of global variable '<string literal>' defined in 
'packet-ieee80211-radio.c:253:5' (0x7f7fa3c484a0) of size 7
  '<string literal>' is ascii string '64-QAM'
0x7f7fa3c48494 is located 45 bytes to the right of global variable '<string literal>' defined in 
'packet-ieee80211-radio.c:249:5' (0x7f7fa3c48460) of size 7
  '<string literal>' is ascii string '16-QAM'
Shadow bytes around the buggy address:
  0x0ff074781040: 00 00 00 00 00 05 f9 f9 f9 f9 f9 f9 00 00 00 00
  0x0ff074781050: 00 00 00 00 00 05 f9 f9 f9 f9 f9 f9 06 f9 f9 f9
  0x0ff074781060: f9 f9 f9 f9 00 00 f9 f9 f9 f9 f9 f9 05 f9 f9 f9
  0x0ff074781070: f9 f9 f9 f9 04 f9 f9 f9 f9 f9 f9 f9 05 f9 f9 f9
  0x0ff074781080: f9 f9 f9 f9 04 f9 f9 f9 f9 f9 f9 f9 07 f9 f9 f9
=>0x0ff074781090: f9 f9[f9]f9 07 f9 f9 f9 f9 f9 f9 f9 04 f9 f9 f9
  0x0ff0747810a0: f9 f9 f9 f9 04 f9 f9 f9 f9 f9 f9 f9 00 f9 f9 f9
  0x0ff0747810b0: f9 f9 f9 f9 00 00 00 00 02 f9 f9 f9 f9 f9 f9 f9
  0x0ff0747810c0: 00 00 00 00 00 00 00 00 07 f9 f9 f9 f9 f9 f9 f9
  0x0ff0747810d0: 00 04 f9 f9 f9 f9 f9 f9 00 00 00 00 02 f9 f9 f9
  0x0ff0747810e0: f9 f9 f9 f9 00 00 00 00 00 00 00 00 01 f9 f9 f9

OK, so either it managed to symbolicate 0x7f7fa3c48494 and 0x7f7fa3c48494 or it somehow found out in some *other* 
fashion that those pointers were before or after string literals defined on specific lines of a specific source file.

Is there some reason that it can't, or doesn't, translate the instruction addresses in the stack trace to lines of code 
in dissectors?

___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe


Current thread: