2

I have a vulnerability trigger (CVE-2018-18492) in Firefox, which crashes and gives SIGSEGV. I used breakpad minidump_stackwalk to get its stack trace from the minidump file produced with the crash. I got something like below:

Thread 0 (crashed)
 0  0xd000b1000d
    rax = 0x00005576254ffac0   rdx = 0x0000000000000000
    rcx = 0x0000000000000001   rbx = 0x0000000000000000
    rsi = 0x0000557623c5e040   rdi = 0x00005576239d7c60
    rbp = 0x00007fffd0546890   rsp = 0x00007fffd0546568
     r8 = 0x0000000044815f7a    r9 = 0x00000000aa7e5e96
    r10 = 0x0000000000000001   r11 = 0x0000000000000001
    r12 = 0x0000557623c5e040   r13 = 0x00007fffd0546910
    r14 = 0x00005576239d7c60   r15 = 0x0000557623c5e040
    rip = 0x000000d000b1000d
    Found by: given as instruction pointer in context
 1  libxul.so!mozilla::dom::HTMLOptionsCollection_Binding::add [HTMLOptionsCollectionBinding.cpp : 165 + 0x1d]
    rbp = 0x00007fffd0546a70   rsp = 0x00007fffd05468a0
    rip = 0x00007f099629754c
    Found by: previous frame's frame pointer
 2  libxul.so!bool mozilla::dom::binding_detail::GenericMethod<mozilla::dom::binding_detail::NormalThisPolicy, mozilla::dom::binding_detail::ThrowExceptions>(JSContext*, unsigned int, JS::Value*) [BindingUtils.cpp : 3296 + 0x9]
    rbx = 0x00007f099c307d10   rbp = 0x00007fffd0546b40
    rsp = 0x00007fffd0546a80   r12 = 0x00000000000000fb
    r13 = 0x00007fffd0546af0   r14 = 0x00007fffd0546ab0
    r15 = 0x00007fffd0546ad0   rip = 0x00007f099638680d
    Found by: call frame info
...

Then I ran with the same thing again with gdb (gdb /path/to/firefox/binary), it crashes again as expected, and I use bt to get the backtrace at the point of crash. However I got something slightly different:

#0  0x000055a17135b810 in  ()
#1  0x00007f23dd134dea in nsINode::ReplaceOrInsertBefore(bool, nsINode*, nsINode*, mozilla::ErrorResult&) (this=0x55a1712a3550, aReplace=<optimized out>, aNewChild=<optimized out>, aRefChild=<optimized out>, aError=...) at /home/ug16zy2/firefox-63.0.3/dom/base/nsINode.cpp:2631
#2  0x00007f23dd8b0e7f in mozilla::dom::HTMLOptionsCollection_Binding::add(JSContext*, JS::Handle<JSObject*>, mozilla::dom::HTMLOptionsCollection*, JSJitMethodCallArgs const&) (cx=0x55a16e7867e0, obj=Python Exception <class 'gdb.error'> No type "Class" within class or namespace "js".:
0x7f23820aaf40, self=0x55a1701b1600, args=...) at /home/ug16zy2/firefox-63.0.3/objdir-ff-dbg/dom/bindings/HTMLOptionsCollectionBinding.cpp:165
#3  0x00007f23dd953158 in mozilla::dom::binding_detail::GenericMethod<mozilla::dom::binding_detail::NormalThisPolicy, mozilla::dom::binding_detail::ThrowExceptions>(JSContext*, unsigned int, JS::Value*) (cx=0x55a16e7867e0, argc=1, vp=0x55a16f509ed0) at /home/ug16zy2/firefox-63.0.3/dom/bindings/BindingUtils.cpp:3296
...

Note the call stack of two outputs. It seems that gdb gives one more function call ReplaceOrInsertBefore on top of add, whereas minidump did not.

Do you know what causes the difference between them and why?

Clover Ye
  • 253
  • 3
  • 8
  • If there's memory (including stack) corruption involved you cannot necessarily trust any generated stack trace. Also; for optimized binaries, the debug information may not be 100% reliable. In extreme cases you may have to inspect the generated assembly. It can get *really* complicated, *really* fast, for some types of bugs. Different compilers may also generate different results - lots of variables. – Jesper Juhl Jan 09 '20 at 18:57

0 Answers0