1391292 - segfault in src/firefox-55.0.1/media/mtransport/third_party/nICEr/src/ice/ice_ctx.c:719

Status: UNCONFIRMED

(Core :: WebRTC: Networking, defect, P5)

Description

[marian.buschsieweke]

Attachment: bt.txt

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:54.0) Gecko/20100101 Firefox/54.0
Build ID: 20170719041525

Steps to reproduce:

Open website aliexpress.com in Firefox 55.0.1 on Alpine Linux


Actual results:

segfault. See bt.txt for the gdb backtrace. The segfault works 10 out of 10 times.


Expected results:

page opend

Comment 1

[Dan Minor [:dminor]]

Thank you for your report!

I'm not able to reproduce your crash using either local or official Firefox builds on Ubuntu. I don't know if Alpine packages it's own version of Firefox; if that's the case, could you please do a quick test with a downloaded build of Firefox 55 to see if that also crashes for you? If that does crash for you, it would be very helpful to know if Nightly also crashes for you.

Comment 2

[marian.buschsieweke]

As far as I know, there are no official builds of Firefox against the musl c library. It might be related to either the use of musl, or to one of the few patches needed to get Firefox build and running on Alpine.

You can find the patches for version 54 here:
https://git.alpinelinux.org/cgit/aports/tree/testing/firefox

A git patch to update to 55.0.1 can be found here:
https://patchwork.alpinelinux.org/patch/3513/

Right now I'm compiling 55.0.2 to see if the problem is still present.

Btw: The tools_profiler_missing_header.patch could be upstreamed. The missing header fixes a Bug in which a #include is missing. The bug is shadows by glibc pulling unrelated headers in and by chance also the required header.

Comment 3

[marian.buschsieweke]

Still present in 55.0.2. The "Disable WebRTC Plugin" prevents the segfault. If the backtrace is correct, it seems to be unrelated to the patches in Alpine, as none of them touches any file in mtransports at all.

Comment 4

[marian.buschsieweke]

Ok, that's weird. I just wanted to create a core dump and share the created binary. I wiped my .profile for privacy reasons and now I'm unable to reproduce the segfault :-( I'll install all of my extensions and see if I can reproduce the problem afterwards

Comment 5

[marian.buschsieweke]

Attachment: Full gdb output of the crash

Comment 6

[marian.buschsieweke]

Attachment: Full gdb output and backtrace of a different crash in mozStorageService.cpp:952

This crash happened on exiting Firefox with an almost clean profile (5 Minutes old) after installing the following extensions:

 - "Copper (Cu)" (Version 1.0.1)
 - "HTTPS Everywhere" (Version 5.2.21)
 - "uBlock Origin" (version 1.13.8)
 - "Video DownloadHelper" (Version 6.3.1.)

Comment 7

[marian.buschsieweke]

I was able to reproduce the crash once with a clean profile after installing the 4 Extensions listed above. But after that, I couldn't get Firefox to crash any more. With my old profile, Firefox still crashes every single time I open "aliexpress.com"

Comment 8

[marian.buschsieweke]

Removing the extension Copper (Cu) solves the problem for my regular profile (that one that crashes 100% of the time when opening aliexpress.com): Without Copper (Cu) my browser no longer crashes. Installing it again and the segfault re-appears.

Comment 9

[Dan Minor [:dminor]]

(In reply to marian.buschsieweke from comment #8)
> Removing the extension Copper (Cu) solves the problem for my regular profile
> (that one that crashes 100% of the time when opening aliexpress.com):
> Without Copper (Cu) my browser no longer crashes. Installing it again and
> the segfault re-appears.

Thank you very much for tracking this down.

Comment 10

[Alex Chronopoulos [:achronop]]

Can we close that bug?

Comment 11

[marian.buschsieweke]

Hi,

receiving a segfault implies that there is a memory Bug. By removing Copper (Cu) I was able to work around the bug, still, the bug cannot be caused by an Firefox Extension written in JavaScript and CSS [1]. This is because no manual memory management is performed in JavaScript, so the bug must be in some C/C++ code belonging to Firefox.

Btw: Memory management Bugs are often security relevant.

Was nobody able so far to reproduce the crash? Even after installing Copper (Cu) or all of the listed extensions?

Kind regards,
Marian

[1]: https://github.com/mkovatsc/Copper

Comment 12

[Dan Minor [:dminor]]

Not sure. It looks like the Copper extension is unsupported in 57 which would make this a low priority, but it could be triggering a real bug in nICEr. Deferring to drno :)

Comment 13

[Nils Ohlmeier [:drno]]

aliexpress.com clearly uses a WebRTC connection for tracking purposes.

I installed all 4 listed extensions in Fx 55 and was not able to repro any crash when loading aliexpress.com.

Where you able to repro this just with Copper installed and non of the other extensions?
I'm asking because for me it would make more sense if uBlock is actually to blame here, because AFAIK uBlock actually messes with PeerConnections in attempts to block tracking via WebRTC.

Comment 14

[marian.buschsieweke]

Hi,

I just reinstalled Copper (Cu) and the segfault reappeared. Even after removing all extensions but Copper (Cu) the segfault appears any time I visit aliexpress. Btw: I tried a couple of other WebRTC enabled sites like https://test.webrtc.org/, but there I don't get a segfault.

Also something in my profile seems to increase the probability of the segfault to happen - I was only able to reproduce the segfault once with a fresh profile and Copper (Cu) installed :-( I'm happy to provide more information, if required.

Kind regards,
Marian