1129855 - SEGV on a high unknown address at SegmentIs

Status: RESOLVED DUPLICATE of bug 1144398

(Core :: Networking, defect)

Description

[Aki Helin]

Attachment: ff-segv-unknown.pdf

ASan builds spot the following crash when the attached pdf file is viewed with firefox. Not sure where to file this in FF, because from the trace this sounds like bad data present / being used from the URI hash, so likely something before the event is being too permissive.

Based on the heapish address this sounds like a potential security issue.

$ opt/firefox-asan-tinderbox/firefox ff-segv-unknown.pdf 2>&1 | symbolize | c++filt | head -n 16
ASAN:SIGSEGV
=================================================================
==27474==ERROR: AddressSanitizer: SEGV on unknown address 0x61410032d232 (pc 0x00000043f3c8 sp 0x7fffb862bfd0 bp 0x7fffb862c010 T0)
    #0 0x43f3c7 in __interceptor_strncmp /builds/slave/moz-toolchain/src/llvm/projects/compiler-rt/lib/sanitizer_common/sanitizer_common_interceptors.inc:104
    #1 0x7f9f41abe2c8 in SegmentIs /builds/slave/m-cen-l64-asan-000000000000000/build/src/netwerk/base/nsStandardURL.cpp:757
    #2 0x7f9f48108420 in KeyEquals /builds/slave/m-cen-l64-asan-000000000000000/build/src/obj-firefox/toolkit/components/places/../../../dist/include/nsURIHashKey.h:32
    #3 0x7f9f41917684 in SearchTable /builds/slave/m-cen-l64-asan-000000000000000/build/src/xpcom/glue/pldhash.cpp:380
    #4 0x7f9f419182c2 in Remove /builds/slave/m-cen-l64-asan-000000000000000/build/src/xpcom/glue/pldhash.cpp:641
    #5 0x7f9f48018819 in RemoveEntry /builds/slave/m-cen-l64-asan-000000000000000/build/src/obj-firefox/toolkit/components/places/../../../dist/include/nsTHashtable.h:176
    #6 0x7f9f461b7b13 in RecvStartVisitedQuery /builds/slave/m-cen-l64-asan-000000000000000/build/src/dom/ipc/ContentParent.cpp:3775
    #7 0x7f9f42712bbd in OnMessageReceived /builds/slave/m-cen-l64-asan-000000000000000/build/src/obj-firefox/ipc/ipdl/./PContentParent.cpp:3699
    #8 0x7f9f4213db81 in DispatchAsyncMessage /builds/slave/m-cen-l64-asan-000000000000000/build/src/ipc/glue/MessageChannel.cpp:1231
    #9 0x7f9f421333f5 in OnMaybeDequeueOne /builds/slave/m-cen-l64-asan-000000000000000/build/src/ipc/glue/MessageChannel.cpp:1142
    #10 0x7f9f420f1524 in RunTask /builds/slave/m-cen-l64-asan-000000000000000/build/src/ipc/chromium/src/base/message_loop.cc:361
    #11 0x7f9f420f25d7 in DoWork /builds/slave/m-cen-l64-asan-000000000000000/build/src/ipc/chromium/src/base/message_loop.cc:447
    #12 0x7f9f42145802 in Run /builds/slave/m-cen-l64-asan-000000000000000/build/src/ipc/glue/MessagePump.cpp:233

Comment 1

[Andrew McCreight [:mccr8]]

jdm, do you have any idea what might be going wrong here?

Comment 2

[Josh Matthews [:jdm]]

Nothing I'm familiar with. Maybe try Marco Bonardo?

Comment 3

[Andrew McCreight [:mccr8]]

Marco, do you have some idea what might be going wrong here?  Thanks.

Comment 4

[Marco Bonardo [:mak]]

Looks like we are here:

http://mxr.mozilla.org/mozilla-central/source/toolkit/components/places/History.cpp#2581

But I can't see what may be causing the segv, I wonder if there's something unexpected in the nsURIHashKey implementation...

Comment 5

[Kamil Jozwiak [:kjozwiak]]

Reproduced the issue from comment #0 using the following builds:

* http://inbound-archive.pub.build.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-central-linux64-asan/1425992124/
* http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2015-03-10-03-02-35-mozilla-central/
* http://inbound-archive.pub.build.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-aurora-linux64-asan/1425973348/
* http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2015-03-10-00-42-28-mozilla-aurora/

I also reproduced the issue on none-asan builds, crash reports: (reproduced crashes on OSX, Win and Linux)

* https://crash-stats.mozilla.com/report/index/3db0e320-338b-4ba7-831d-e704d2150310
* https://crash-stats.mozilla.com/report/index/202c0d33-9ca4-4231-854c-61e322150310
* https://crash-stats.mozilla.com/report/index/02981af0-f275-4a1a-85aa-501492150310

I couldn't reproduce the issue on asan/none-asan builds of BETA (fx37) and Release (fx36)

Comment 6

[Daniel Veditz [:dveditz]]

If we're treating random junk as URLs as implied by bp-3db0e320-338b-4ba7-831d-e704d2150310 it looks like we've got some kind of memory corruption.

Comment 7

[Daniel Veditz [:dveditz]]

bisecting the regressor would probably go a long way to pointing at the cause.

Comment 8

[Kamil Jozwiak [:kjozwiak]]

Went through mozregression twice and got the same bisect range. Appears that Bug # 1093611 is the culprit. Let me know if you need more information Dan.

17:28.10 LOG: MainThread Bisector INFO Last good revision: 0881f9a22f4a
17:28.10 LOG: MainThread Bisector INFO First bad revision: 3d4ea993d8f0
17:28.10 LOG: MainThread Bisector INFO Pushlog:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=0881f9a22f4a&tochange=3d4ea993d8f0

Comment 9

[Daniel Veditz [:dveditz]]

Valentin: please check whether this is indeed a regression from your check-in. Touching the guts of nsStandardURL is always treacherous.

Comment 10

[Valentin Gosu [:valentin]]

This is clearly related to my checkin. It can be easily proved and fixed by flipping the dom.url.encode_decode_hash pref.
I've played around with the URL from the pdf file, and just parsing it doesn't seem to corrupt anything.
It seems we have a bunch of code calls uri->GetSpec (which may contain unescaped UTF8) instead of uri->GetAsciiSpec (in History and ImgLoader at least). I'm looking into whether this is fixable, or if we should back out or pref off this feature.

Comment 11

[Valentin Gosu [:valentin]]

This is the same bug as Bug 1144398.
Parsing a URL containing a null character messes up the index of the ref part. It doesn't crash right away, only when someone tries to use the data in the URL and ends up in unallocated memory.
I have posted a patch in Bug 1144398.