Closed Bug 987380 Opened 6 years ago Closed 5 years ago

Crash in NrSocket::~NrSocket()

Categories

(Core :: WebRTC: Networking, defect)

x86
macOS
defect
Not set

Tracking

()

RESOLVED DUPLICATE of bug 891551

People

(Reporter: ekr, Assigned: bwc)

Details

Attachments

(1 file)

Attached file crash.txt
If NrSocket::Create() fails early, we can be left trying to PR_Close(0),
which causes a crash in dereferencing fd->methods.

No STR, but I can imagine a number of ways this might happen.
Note that fd_ is properly initialized to nullptr at:

http://dxr.mozilla.org/mozilla-central/source/media/mtransport/nr_socket_prsock.h?from=~NrSocket#128

So the fix here is just to add an if(fd_) { } around the PR_Close() in :

http://dxr.mozilla.org/mozilla-central/source/media/mtransport/nr_socket_prsock.h?from=~NrSocket#130


I marked this as security because I am unsure of our policy around NULL ptr deref.
Actually, I do have reported STR, but on a wacky branch and on Windows. I have asked
ehugg to repro.

Hi, EKR, 
  I just get a crash,  the case is:  Firefox branch: gmp7,  openh264 branch: plugin2
    1.  start p2p video call,   but after a while, the video freeze. 
    2.  stop and start video again,    then crash,  please check the crash stack at attachment.
ehugg points out not win....
guaranteed null pointer deref (unless there's an arbitrary offset that's added, like a string length) is not a sec bug.  If it's random-memory-that-happens-to-be-null, that might be a sec bug.
Group: core-security
Assignee: nobody → docfaraday
I should point out that the ICE TCP patch already has a fix for this:

https://bug891551.bugzilla.mozilla.org/attachment.cgi?id=8398368
Closing, since the fix for this landed as part of bug 891551.
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 891551
You need to log in before you can comment on or make changes to this bug.