AddressSanitizer: heap-use-after-free [@ mozilla::layers::CopyableCanvasRenderer::Initialize] with READ of size 8
Categories
(Core :: Graphics: WebRender, defect)
Tracking
()
Tracking | Status | |
---|---|---|
firefox67 | --- | fixed |
People
(Reporter: decoder, Unassigned)
Details
(Keywords: crash, csectype-uaf, regression, Whiteboard: [adv-main67-])
Attachments
(1 file)
12.44 KB,
text/plain
|
Details |
The attached crash information was submitted via the ASan Nightly Reporter on mozilla-central-asan-nightly revision 67.0a1-20190211215545-https://hg.mozilla.org/mozilla-central/rev/b9187fa10f13a7b84f21c973d33d2fdb0f37bbb0.
For detailed crash information, see attachment.
Reporter | ||
Comment 1•5 years ago
|
||
Reporter | ||
Comment 2•5 years ago
|
||
I suddenly received 3 of these reports, all just with _tls_end
on the stack. No clue what this is about.
Comment 3•5 years ago
|
||
Any way to re-symbolize these with something that makes more sense?
Comment 4•5 years ago
|
||
(In reply to Daniel Veditz [:dveditz] from comment #3)
Any way to re-symbolize these with something that makes more sense?
I tried but got the same results. The stack output seems bogus but I'm guessing there is a legitimate UAF here.
:dmajor any idea what may be causing the invalid stack output?
It's webrender.
For reference here's what I did:
- Open target.zip from https://treeherder.mozilla.org/#/jobs?repo=mozilla-central&revision=b9187fa10f13a7b84f21c973d33d2fdb0f37bbb0&searchStr=reporter&selectedJob=227757714
- Extract xul.{dll,pdb} and load in windbg
- For each frame where ASan complains about
xul.dll+0x123456
, in windbg typeub xul+123456+1 L1
, which means, "unassemble backwards, from the next address, 1 instruction" (ASan points to the last byte of the faulting instruction, so you have to increment by one byte and then go back one instruction, for it to make sense.)
Here's the first few, you can repeat if more is needed:
0:000> ub xul+2e23a5b+1 L1
xul!mozilla::layers::CopyableCanvasRenderer::Initialize+0x9c7 [z:\build\build\src\gfx\layers\CopyableCanvasRenderer.cpp @ 57]:
00000001`82e23a57 e80489a00e call xul!_asan_report_load8 (00000001`9182c360)
0:000> ub xul+2e9bd46+1 L1
xul!mozilla::layers::ShareableCanvasRenderer::Initialize+0xe2 [z:\build\build\src\gfx\layers\ShareableCanvasRenderer.cpp @ 37]:
00000001`82e9bd42 e84973f8ff call xul!mozilla::layers::CopyableCanvasRenderer::Initialize (00000001`82e23090)
0:000> ub xul+2fd46a0+1 L1
xul!mozilla::layers::WebRenderCanvasRendererAsync::Initialize+0xec [z:\build\build\src\gfx\layers\wr\WebRenderCanvasRenderer.cpp @ 31]:
00000001`82fd469c e8bf75ecff call xul!mozilla::layers::ShareableCanvasRenderer::Initialize (00000001`82e9bc60)
0:000> ub xul+7a873cc+1 L1
xul!mozilla::WebGLContext::InitializeCanvasRenderer+0x4bb [z:\build\build\src\dom\canvas\WebGLContext.cpp @ 1211]:
00000001`87a873cb ff10 call qword ptr [rax]
0:000> ub xul+7a86e92+1 L1
xul!mozilla::WebGLContext::UpdateWebRenderCanvasData+0x80 [z:\build\build\src\dom\canvas\WebGLContext.cpp @ 1170]:
00000001`87a86e90 ff5500 call qword ptr [rbp]
0:000> ub xul+b0dd8df+1 L1
xul!nsDisplayCanvas::CreateWebRenderCommands+0x2cb [z:\build\build\src\layout\generic\nsHTMLCanvasFrame.cpp @ 135]:
00000001`8b0dd8db e8f0ba28fd call xul!mozilla::dom::HTMLCanvasElement::UpdateWebRenderCanvasData (00000001`883693d0)
Updated•5 years ago
|
Comment 6•5 years ago
|
||
Thanks :dmajor :)
Reporter | ||
Comment 7•5 years ago
|
||
Likely a dup of bug 1506665 then. Thanks :dmajor !
Updated•5 years ago
|
Updated•5 years ago
|
Updated•5 years ago
|
Updated•11 months ago
|
Description
•