Closed
Bug 1410363
Opened 7 years ago
Closed 7 years ago
Firefox crashes with NoScript installed when visiting http://eli.fox-epste.in/rule110/
Categories
(Core :: Graphics, defect)
Tracking
()
RESOLVED
DUPLICATE
of bug 1338771
People
(Reporter: gk, Unassigned)
References
()
Details
Attachments
(1 file)
1.11 KB,
patch
|
Details | Diff | Splinter Review |
Steps to reproduce
1) Grab the latest stable Firefox (ESR works as well)
2) Install NoScript
3) Go to http://eli.fox-epste.in/rule110/
4) The tab crashes
This happens on different Linux machines at least. It seems that Windows might not be affected. I might not have tested hard enough, though, and I don't have a macOS machine handy right now.
Interestingly enough setting `javascript.enabled` to `false` in the browser does not trigger the crash if NoScript is not installed.
Not sure if that is uncovering a deeper, problematic issue. Thus, marking this as a security bug.
This came up on #tor today. Thanks to the IRC user "popup" who helped to debug this and reported this problem in the first place.
Reporter | ||
Comment 1•7 years ago
|
||
I looked a bit closer at it and it the issue does not happen if e10s is not enabled. Furthermore my ASan build (52.4.1esr) gives me:
ASAN:DEADLYSIGNAL
=================================================================
==28201==ERROR: AddressSanitizer: SEGV on unknown address 0x7f8d290a5000 (pc 0x7f8e38219e20 bp 0x7ffe3bedd6a0 sp 0x7ffe3bedd6a0 T0)
#0 0x7f8e38219e1f in ARGBSetRow_X86 /home/thomas/Arbeit/Tor/tor-browser/media/libyuv/source/row_gcc.cc:3057
#1 0x7f8e3820829f in ARGBRect /home/thomas/Arbeit/Tor/tor-browser/media/libyuv/source/planar_functions.cc:1263
#2 0x7f8e385522ee in InitBuffer /home/thomas/Arbeit/Tor/tor-browser/gfx/layers/BufferTexture.cpp:454
#3 0x7f8e3855ff18 in mozilla::layers::ShmemTextureData::Create(mozilla::gfx::IntSizeTyped<mozilla::gfx::UnknownUnits>, mozilla::gfx::SurfaceFormat, mozilla::gfx::BackendType, mozilla::layers::LayersBackend, mozilla::layers::TextureFlags, mozilla::layers::TextureAllocationFlags, mozilla::layers::LayersIPCChannel*) /home/thomas/Arbeit/Tor/tor-browser/gfx/layers/BufferTexture.cpp:564
#4 0x7f8e38615953 in mozilla::layers::TextureClient::CreateForRawBufferAccess(mozilla::layers::LayersIPCChannel*, mozilla::gfx::SurfaceFormat, mozilla::gfx::IntSizeTyped<mozilla::gfx::UnknownUnits>, mozilla::gfx::BackendType, mozilla::layers::LayersBackend, mozilla::layers::TextureFlags, mozilla::layers::TextureAllocationFlags) /home/thomas/Arbeit/Tor/tor-browser/gfx/layers/client/TextureClient.cpp:1203
#5 0x7f8e38615be6 in mozilla::layers::TextureClient::CreateForDrawing(mozilla::layers::TextureForwarder*, mozilla::gfx::SurfaceFormat, mozilla::gfx::IntSizeTyped<mozilla::gfx::UnknownUnits>, mozilla::layers::LayersBackend, int, mozilla::layers::BackendSelector, mozilla::layers::TextureFlags, mozilla::layers::TextureAllocationFlags) /home/thomas/Arbeit/Tor/tor-browser/gfx/layers/client/TextureClient.cpp:1096
#6 0x7f8e38615cf1 in mozilla::layers::TextureClient::CreateForDrawing(mozilla::layers::KnowsCompositor*, mozilla::gfx::SurfaceFormat, mozilla::gfx::IntSizeTyped<mozilla::gfx::UnknownUnits>, mozilla::layers::BackendSelector, mozilla::layers::TextureFlags, mozilla::layers::TextureAllocationFlags) /home/thomas/Arbeit/Tor/tor-browser/gfx/layers/client/TextureClient.cpp:1001
#7 0x7f8e38615d72 in mozilla::layers::CompositableClient::CreateTextureClientForDrawing(mozilla::gfx::SurfaceFormat, mozilla::gfx::IntSizeTyped<mozilla::gfx::UnknownUnits>, mozilla::layers::BackendSelector, mozilla::layers::TextureFlags, mozilla::layers::TextureAllocationFlags) /home/thomas/Arbeit/Tor/tor-browser/gfx/layers/client/CompositableClient.cpp:151
#8 0x7f8e38617ea7 in mozilla::layers::ContentClientRemoteBuffer::CreateBackBuffer(mozilla::gfx::IntRectTyped<mozilla::gfx::UnknownUnits> const&) /home/thomas/Arbeit/Tor/tor-browser/gfx/layers/client/ContentClient.cpp:315
#9 0x7f8e38618475 in mozilla::layers::ContentClientDoubleBuffered::EnsureBackBufferIfFrontBuffer() /home/thomas/Arbeit/Tor/tor-browser/gfx/layers/client/ContentClient.cpp:605
#10 0x7f8e3860b05e in mozilla::layers::ContentClientRemoteBuffer::BeginPaint() /home/thomas/Arbeit/Tor/tor-browser/gfx/layers/client/ContentClient.cpp:231
#11 0x7f8e3860b10a in mozilla::layers::ContentClientDoubleBuffered::BeginPaint() /home/thomas/Arbeit/Tor/tor-browser/gfx/layers/client/ContentClient.cpp:499
#12 0x7f8e385e9b55 in mozilla::layers::ClientPaintedLayer::RenderLayerWithReadback(mozilla::layers::ReadbackProcessor*) /home/thomas/Arbeit/Tor/tor-browser/gfx/layers/client/ClientPaintedLayer.cpp:136
#13 0x7f8e385fcb8e in mozilla::layers::ClientContainerLayer::RenderLayer() /home/thomas/Arbeit/Tor/tor-browser/gfx/layers/client/ClientContainerLayer.h:62
#14 0x7f8e385fcb8e in mozilla::layers::ClientContainerLayer::RenderLayer() /home/thomas/Arbeit/Tor/tor-browser/gfx/layers/client/ClientContainerLayer.h:62
#15 0x7f8e385e0841 in mozilla::layers::ClientLayerManager::EndTransactionInternal(void (*)(mozilla::layers::PaintedLayer*, gfxContext*, mozilla::gfx::IntRegionTyped<mozilla::gfx::UnknownUnits> const&, mozilla::gfx::IntRegionTyped<mozilla::gfx::UnknownUnits> const&, mozilla::layers::DrawRegionClip, mozilla::gfx::IntRegionTyped<mozilla::gfx::UnknownUnits> const&, void*), void*, mozilla::layers::LayerManager::EndTransactionFlags) /home/thomas/Arbeit/Tor/tor-browser/gfx/layers/client/ClientLayerManager.cpp:326
#16 0x7f8e385f7908 in mozilla::layers::ClientLayerManager::EndTransaction(void (*)(mozilla::layers::PaintedLayer*, gfxContext*, mozilla::gfx::IntRegionTyped<mozilla::gfx::UnknownUnits> const&, mozilla::gfx::IntRegionTyped<mozilla::gfx::UnknownUnits> const&, mozilla::layers::DrawRegionClip, mozilla::gfx::IntRegionTyped<mozilla::gfx::UnknownUnits> const&, void*), void*, mozilla::layers::LayerManager::EndTransactionFlags) /home/thomas/Arbeit/Tor/tor-browser/gfx/layers/client/ClientLayerManager.cpp:379
#17 0x7f8e3a8584e7 in nsDisplayList::PaintRoot(nsDisplayListBuilder*, nsRenderingContext*, unsigned int) /home/thomas/Arbeit/Tor/tor-browser/layout/base/nsDisplayList.cpp:1990
#18 0x7f8e3a859219 in nsLayoutUtils::PaintFrame(nsRenderingContext*, nsIFrame*, nsRegion const&, unsigned int, nsDisplayListBuilderMode, nsLayoutUtils::PaintFrameFlags) /home/thomas/Arbeit/Tor/tor-browser/layout/base/nsLayoutUtils.cpp:3653
#19 0x7f8e3a85c30d in PresShell::Paint(nsView*, nsRegion const&, unsigned int) /home/thomas/Arbeit/Tor/tor-browser/layout/base/nsPresShell.cpp:6422
#20 0x7f8e3a34a3ae in nsViewManager::ProcessPendingUpdatesPaint(nsIWidget*) /home/thomas/Arbeit/Tor/tor-browser/view/nsViewManager.cpp:484
#21 0x7f8e3a34ab5a in nsViewManager::ProcessPendingUpdatesForView(nsView*, bool) /home/thomas/Arbeit/Tor/tor-browser/view/nsViewManager.cpp:415
#22 0x7f8e3a34adf2 in nsViewManager::ProcessPendingUpdates() /home/thomas/Arbeit/Tor/tor-browser/view/nsViewManager.cpp:1118
#23 0x7f8e3a6db060 in nsRefreshDriver::Tick(long, mozilla::TimeStamp) /home/thomas/Arbeit/Tor/tor-browser/layout/base/nsRefreshDriver.cpp:2012
#24 0x7f8e3a6e2292 in mozilla::RefreshDriverTimer::TickRefreshDrivers(long, mozilla::TimeStamp, nsTArray<RefPtr<nsRefreshDriver> >&) /home/thomas/Arbeit/Tor/tor-browser/layout/base/nsRefreshDriver.cpp:295
#25 0x7f8e3a6e2473 in mozilla::RefreshDriverTimer::Tick(long, mozilla::TimeStamp) /home/thomas/Arbeit/Tor/tor-browser/layout/base/nsRefreshDriver.cpp:317
#26 0x7f8e3a6e2857 in mozilla::VsyncRefreshDriverTimer::RunRefreshDrivers(mozilla::TimeStamp) /home/thomas/Arbeit/Tor/tor-browser/layout/base/nsRefreshDriver.cpp:663
#27 0x7f8e3a6e2857 in mozilla::VsyncRefreshDriverTimer::RefreshDriverVsyncObserver::TickRefreshDriver(mozilla::TimeStamp) /home/thomas/Arbeit/Tor/tor-browser/layout/base/nsRefreshDriver.cpp:583
#28 0x7f8e3a6e2b2e in mozilla::VsyncRefreshDriverTimer::RefreshDriverVsyncObserver::NotifyVsync(mozilla::TimeStamp) /home/thomas/Arbeit/Tor/tor-browser/layout/base/nsRefreshDriver.cpp:501
#29 0x7f8e3abb8485 in mozilla::layout::VsyncChild::RecvNotify(mozilla::TimeStamp const&) /home/thomas/Arbeit/Tor/tor-browser/layout/ipc/VsyncChild.cpp:64
#30 0x7f8e37ed4049 in mozilla::layout::PVsyncChild::OnMessageReceived(IPC::Message const&) /home/thomas/Arbeit/Tor/tor-browser/obj-x86_64-pc-linux-gnu/ipc/ipdl/PVsyncChild.cpp:169
#31 0x7f8e37cc26fc in mozilla::ipc::PBackgroundChild::OnMessageReceived(IPC::Message const&) /home/thomas/Arbeit/Tor/tor-browser/obj-x86_64-pc-linux-gnu/ipc/ipdl/PBackgroundChild.cpp:1449
#32 0x7f8e37c12155 in mozilla::ipc::MessageChannel::DispatchAsyncMessage(IPC::Message const&) /home/thomas/Arbeit/Tor/tor-browser/ipc/glue/MessageChannel.cpp:1743
#33 0x7f8e37c2208f in mozilla::ipc::MessageChannel::DispatchMessage(IPC::Message&&) /home/thomas/Arbeit/Tor/tor-browser/ipc/glue/MessageChannel.cpp:1681
#34 0x7f8e37c24cf1 in mozilla::ipc::MessageChannel::RunMessage(mozilla::ipc::MessageChannel::MessageTask&) /home/thomas/Arbeit/Tor/tor-browser/ipc/glue/MessageChannel.cpp:1572
#35 0x7f8e37c25193 in mozilla::ipc::MessageChannel::MessageTask::Run() /home/thomas/Arbeit/Tor/tor-browser/ipc/glue/MessageChannel.cpp:1597
#36 0x7f8e37491d52 in nsThread::ProcessNextEvent(bool, bool*) /home/thomas/Arbeit/Tor/tor-browser/xpcom/threads/nsThread.cpp:1216
#37 0x7f8e374df89e in NS_ProcessNextEvent(nsIThread*, bool) /home/thomas/Arbeit/Tor/tor-browser/xpcom/glue/nsThreadUtils.cpp:361
#38 0x7f8e37c0ab3b in mozilla::ipc::MessagePump::Run(base::MessagePump::Delegate*) /home/thomas/Arbeit/Tor/tor-browser/ipc/glue/MessagePump.cpp:96
#39 0x7f8e37b8a764 in MessageLoop::RunHandler() /home/thomas/Arbeit/Tor/tor-browser/ipc/chromium/src/base/message_loop.cc:225
#40 0x7f8e37b8a764 in MessageLoop::Run() /home/thomas/Arbeit/Tor/tor-browser/ipc/chromium/src/base/message_loop.cc:205
#41 0x7f8e3a396071 in nsBaseAppShell::Run() /home/thomas/Arbeit/Tor/tor-browser/widget/nsBaseAppShell.cpp:156
#42 0x7f8e3b1ea89c in XRE_RunAppShell /home/thomas/Arbeit/Tor/tor-browser/toolkit/xre/nsEmbedFunctions.cpp:866
#43 0x7f8e37b8a764 in MessageLoop::RunHandler() /home/thomas/Arbeit/Tor/tor-browser/ipc/chromium/src/base/message_loop.cc:225
#44 0x7f8e37b8a764 in MessageLoop::Run() /home/thomas/Arbeit/Tor/tor-browser/ipc/chromium/src/base/message_loop.cc:205
#45 0x7f8e3b1eb8c3 in XRE_InitChildProcess /home/thomas/Arbeit/Tor/tor-browser/toolkit/xre/nsEmbedFunctions.cpp:698
#46 0x55f4b54042c0 in content_process_main(int, char**) /home/thomas/Arbeit/Tor/tor-browser/browser/app/../../ipc/contentproc/plugin-container.cpp:197
#47 0x55f4b5403671 in main /home/thomas/Arbeit/Tor/tor-browser/browser/app/nsBrowserApp.cpp:392
#48 0x7f8e42d552e0 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x202e0)
#49 0x55f4b5403cd9 in _start (/home/thomas/Arbeit/Tor/tor-browser-bundle/tor-browser_en-US/Browser/firefox+0x8cd9)
AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV /home/thomas/Arbeit/Tor/tor-browser/media/libyuv/source/row_gcc.cc:3057 in ARGBSetRow_X86
==28201==ABORTING
So at first glance it seems like a duplicate of https://bugzilla.mozilla.org/show_bug.cgi?id=1338771. However, the weird thing is the role NoScript plays here as without it I don't get Firefox to crash on the same machine. Hrm.
Component: Security → Graphics
Comment 2•7 years ago
|
||
Bug 1338771 is about getting SIGBUS, which (at least on Linux) indicates an I/O error; in that case the root cause was running out of space in /dev/shm.
I believe SIGSEGV means there's a problem with the mapping itself — that it's absent or the permissions are wrong — which would suggest a use-after-free or perhaps a race condition of some kind.
Comment 3•7 years ago
|
||
(In reply to Georg Koppen from comment #0)
> 1) Grab the latest stable Firefox (ESR works as well)
> 2) Install NoScript
> 3) Go to http://eli.fox-epste.in/rule110/
> 4) The tab crashes
>
> [...] I don't have a macOS machine handy right now.
On Mac with latest stable (Firefox 56) and latest NoScript (5.1.3 -- legacy) I don't crash on that URL. I also can't find any crashes in our crash reporter that mention that site, which is too bad because a non-ASAN stack might have added some information. It's possible you disabled crash reporting.
If this were the WebExtension version of NoScript it would be very easy to blame Firefox. The legacy version has much deeper hooks and perhaps didn't keep up with some of the internal refactorings (one of the reasons we want to kill off legacy add-ons).
Could simply be that NoScript is using up more resources, or keeping Firefox things alive longer, and this has nothing to do with blocking scripts per se but is just a more reliable way of reproducing bug 1338771.
Group: core-security → gfx-core-security
Comment 5•7 years ago
|
||
I don't think this is really a dup of bug 1338771, but there's a way to find out: take attachment 8715007 [details] [diff] [review], put a HANDLE_EINTR around the posix_fallocate call, and try the STR. If it's bug 1338771, the posix_fallocate call will fail and it won't crash in the middle of image conversion code.
Reporter | ||
Comment 6•7 years ago
|
||
(In reply to Jed Davis [:jld] (⏰UTC-6) from comment #5)
> I don't think this is really a dup of bug 1338771, but there's a way to find
> out: take attachment 8715007 [details] [diff] [review], put a HANDLE_EINTR
> around the posix_fallocate call, and try the STR. If it's bug 1338771, the
> posix_fallocate call will fail and it won't crash in the middle of image
> conversion code.
Thanks for that. I took the attached patch and compiled a vanilla Firefox 52.4.1esr with it. I followed my steps to reproduce on the same machine I got the original crashes on. It does not crash. I just get a bunch of messages like
[GFX1-]: Failed 2 buffer db=0 dw=0 for 0, 0, 1667, 919
[GFX1-]: Failed 2 buffer db=0 dw=0 for 0, 0, 1668, 891
in my terminal.
Then I just reverted that commit, recompiled and it crashed again. So, it seems Dan is right. And, yes, this is 100% reproducible for me.
Reporter | ||
Comment 7•7 years ago
|
||
Making a duplicate of bug 1338771 based on comment 6.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → DUPLICATE
Reporter | ||
Comment 9•7 years ago
|
||
Jed, do you think we could just use the attached patch and get rid of that crash in Tor Browser? Or does there speak anything against that?
Flags: needinfo?(jld)
Comment 10•7 years ago
|
||
(In reply to Georg Koppen from comment #9)
> Jed, do you think we could just use the attached patch and get rid of that
> crash in Tor Browser? Or does there speak anything against that?
I tried pushing (approximately) that patch to Try, and there are some failures that look related:
https://treeherder.mozilla.org/#/jobs?repo=try&revision=c11a0b6b5c504f0fdaf0442108a6dea5c1aec2ae&selectedJob=142887003
These tests don't normally crash with SIGBUS, so something unexpected is going on here.
Flags: needinfo?(jld)
Updated•5 years ago
|
Group: gfx-core-security
You need to log in
before you can comment on or make changes to this bug.
Description
•