1404686 - Crash - WebRtc - Null Pointer dereference in nsWrapperCache::HasWrapperFlag

Status: RESOLVED FIXED

(Core :: WebRTC: Signaling, defect, P2)

Description

[Looben Yang]

Attachment: NullPtr_HasWrapperFlag_Repro.html

Reproduction test case (NullPtr_HasWrapperFlag_Repro.html):

	<script>var context = new AudioContext();
	var streamDestNode  = context.createMediaStreamDestination();
	var rtcConfig = { "iceServers": [{ "urls": "stun:stun2.l.google.com:19302" },  ] };
	var options = {optional:[{DtlsSrtpKeyAgreement:true}, {RtpDataChannels: false}]};
	var interval0;var pc0 = new RTCPeerConnection(rtcConfig,options);
	pc0.onicecandidate = function (e) { pc0.addStream(streamDestNode.stream);}; 
	pc0.ontrack  = function (e) { pc0.close();}; 
	pc0.onnegotiationneeded = function(e) {
	pc0.createOffer(function(offer) {pc0.setRemoteDescription(new RTCSessionDescription(offer), function(){},function(e){}); pc0.createAnswer(function(answer) {pc0.setLocalDescription(new RTCSessionDescription(answer), function(){},function(){});}, function(){});
	}, function(e) {});
	}
	pc0.createDataChannel("DataChanName0"); 
	setTimeout(function(){location.reload()},200);</script>
		
Steps to reproduce: 
	1. Open PoC in Firefox browser.
	2. Firefox crashes by deferenceing NULL pointer in nsWrapperCache::HasWrapperFlag.

Firefox version: 58.0a1 (2017-09-30) (32-bit)
OS: Windows 10

Stack trace:


	(9ac.24e0): Access violation - code c0000005 (!!! second chance !!!)
	eax=00000008 ebx=00b7cd54 ecx=00000004 edx=00000008 esi=00b7c808 edi=0111b800
	eip=5fbd71ff esp=00b7c788 ebp=00b7c914 iopl=0         nv up ei pl zr na pe nc
	cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00210246
	xul!nsWrapperCache::HasWrapperFlag+0x16 [inlined in xul!mozilla::dom::PeerConnectionObserverJSImpl::OnAddStream+0xb5]:
	5fbd71ff 8a00            mov     al,byte ptr [eax]          ds:002b:00000008=??


	xul!nsWrapperCache::HasWrapperFlag+0x16
	xul!nsWrapperCache::IsDOMBinding+0x16
	xul!mozilla::dom::CouldBeDOMBinding+0x16
	xul!mozilla::dom::binding_detail::DoGetOrCreateDOMReflector+0x16
	xul!mozilla::dom::GetOrCreateDOMReflector+0x16
	xul!mozilla::dom::GetOrCreateDOMReflectorHelper<mozilla::DOMMediaStream,0>::GetOrCreate+0x16
	xul!mozilla::dom::GetOrCreateDOMReflector+0x16
	xul!mozilla::dom::PeerConnectionObserverJSImpl::OnAddStream+0xb5
	xul!mozilla::dom::PeerConnectionObserver::OnAddStream+0x1c
	xul!mozilla::PeerConnectionImpl::CreateNewRemoteTracks+0x675
	xul!mozilla::PeerConnectionImpl::SetRemoteDescription+0x2b7
	xul!mozilla::PeerConnectionImpl::SetRemoteDescription+0x26
	xul!mozilla::dom::PeerConnectionImplBinding::setRemoteDescription+0xc3
	xul!mozilla::dom::GenericBindingMethod+0xf4
	xul!js::CallJSNative+0x98
	xul!js::InternalCallOrConstruct+0x145
	xul!InternalCall+0x73
	xul!Interpret+0x59b5
	xul!js::RunScript+0x350
	xul!js::InternalCallOrConstruct+0x25c

Comment 1

[Andreas Pehrson [:pehrsons]]

Nils, could you take a look at this?

Comment 2

[Alex Chronopoulos [:achronop]]

I am able to repro at first try:
https://crash-stats.mozilla.com/report/index/345e66e0-0684-40d5-8bbd-f23ef0171006

Comment 3

[Nils Ohlmeier [:drno]]

It's easy to fix this by simply putting a null pointer check here https://dxr.mozilla.org/mozilla-central/rev/19b32a138d08f73961df878a29de6f0aad441683/media/webrtc/signaling/src/peerconnection/PeerConnectionImpl.cpp#1967

But I think the real underlying problem here is that the code for the ontrack callback, closing the connection in this case, gets executed before we are even finished with executing our own setRemoteDescription() code.

Comment 4

[Nils Ohlmeier [:drno]]

I just verified that the work in bug 1290948 is going to fix this issue.

Comment 5

[Nils Ohlmeier [:drno]]

I ran this with today's Firefox 59 Nightly for 5 minutes without any crashes. I think we can call this one fixed through the landing of bug 1290948.