Asan spots a stack buffer overflow when converting a floating point number into its printable form for use in console. The conversion uses a fixed 300-byte buffer for this purpose, so it seems to be easy to steal data from stack this way. ==5182==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7fff3304570c at pc 0x45e1d6 bp 0x7fff33045450 sp 0x7fff33045428 READ of size 1025 at 0x7fff3304570c thread T0 ==5182==WARNING: Trying to symbolize code, but external symbolizer is not initialized! #0 0x45e1d5 in __interceptor_strlen _asan_rtl_ #1 0x7f3143ed0f6e in cvt_f /home/aki/src/mozilla-aurora/nsprpub/pr/src/io/prprf.c:342 #2 0x7f3143ecf375 in PR_vsxprintf /home/aki/src/mozilla-aurora/nsprpub/pr/src/io/prprf.c:1073 #3 0x7f3138a649e4 in nsAString_internal::AppendPrintf(char const*, ...) /home/aki/src/mozilla-aurora/xpcom/string/src/nsTSubstring.cpp:836 #4 0x7f313b6fafd8 in mozilla::dom::Console::ProcessArguments(JSContext*, nsTArray<JS::Heap<JS::Value> > const&, mozilla::dom::Sequence<JS::Value>&, mozilla::dom::Sequence<JS::Value>&) /home/aki/src/mozilla-aurora/dom/base/Console.cpp:1410 #5 0x7f313b6f738a in mozilla::dom::Console::ProcessCallData(mozilla::dom::ConsoleCallData*) /home/aki/src/mozilla-aurora/dom/base/Console.cpp:1072 #6 0x7f313b6f6a90 in mozilla::dom::Console::Notify(nsITimer*) /home/aki/src/mozilla-aurora/dom/base/Console.cpp:970 #7 0x7f3138b56fbc in nsTimerImpl::Fire() /home/aki/src/mozilla-aurora/xpcom/threads/nsTimerImpl.cpp:558 #8 0x7f3138b57549 in nsTimerEvent::Run() /home/aki/src/mozilla-aurora/xpcom/threads/nsTimerImpl.cpp:639 #9 0x7f3138b4e40c in nsThread::ProcessNextEvent(bool, bool*) /home/aki/src/mozilla-aurora/xpcom/threads/nsThread.cpp:715 [...]

Which buffer is being overflowed? And what are the values of `format` and `v` at the point of the crash?

The buffer fout of cvt_f in nsprpub/pr/src/io/prprf.c. The repro ends up doing sprintf(fout, "%1024.1f", NaN), which needs more than the fixed 300 bytes of space allocated in stack for fout. There are no issues if you truncate the output by switching to snprintf(fout, 300, fin, d). Might make sense to cap it, in case this can also happen via other routes, and assert in debug builds if the buffer got totally filled/truncated.