cfi-derived-cast: Invalid downcast in ExecutionRunnable::RunOnWorkletThread
Categories
(Core :: Audio/Video, defect)
Tracking
()
People
(Reporter: lukas.bernhard, Assigned: mccr8)
References
(Blocks 1 open bug, Regression)
Details
(4 keywords, Whiteboard: [adv-main111+][adv-esr102.9+])
Attachments
(2 files)
48 bytes,
text/x-phabricator-request
|
dmeehan
:
approval-mozilla-esr102+
|
Details | Review |
210 bytes,
text/plain
|
Details |
Steps to reproduce:
When compiling Firefox with cfi-derived-cast, crashtest dom/media/test/crashtests/audioworkletnode-after-unload-1.html fails due to the downcasting here:
https://searchfox.org/mozilla-central/rev/daf613efc5c358f3a94961d73b90472c00703838/dom/worklet/Worklet.cpp#410
The dynamic type of the casted object is nsThread
, a parent class of WorkletThread
.
This might not be s-s, just flagging as a precaution.
Reporter | ||
Updated•2 years ago
|
Updated•2 years ago
|
Comment 1•2 years ago
•
|
||
The relevant code has been implemented for web audio, so moving this bug there.
I'm not familiar with the setup, see https://searchfox.org/mozilla-central/rev/7426a35738cd542b9488c7b67f4f6d21edfeda0a/dom/worklet/Worklet.cpp#370-375
Updated•2 years ago
|
Comment 2•2 years ago
|
||
Andrew looked and it appears to only be touched by static methods rather than virtual and is probably OK until a compiler decides to go optimize some undefined behavior. Should fix.
Assignee | ||
Comment 3•2 years ago
|
||
Specifically, we first call EnsureCycleCollectedJSContext on it, which is a non-static non-virtual method that does not touch any fields. It passes this
into the closure argument of JS::InitDispatchToEventLoop, which eventually ends up getting passed back in to the static method DispatchToEventLoop, which casts it back to WorkletThread and calls DispatchRunnable on it, which is a non-static, non-virtual method, that also does not touch any fields.
Assignee | ||
Updated•2 years ago
|
Assignee | ||
Comment 4•2 years ago
|
||
I started throwing together a patch to fix this, and it looks like I was wrong. In WorkletThread::DispatchRunnable(), nsThread::Dispatch() is actually a virtual method on the parent class nsThread. I guess it works out anyways because NS_GetCurrentThread() returns an nsThread and I suppose there's no weird multiple inheritance so the vtables are compatible at least for that one method?
Assignee | ||
Comment 5•2 years ago
|
||
I'm guessing it must be okay because otherwise it would just crash every time.
Assignee | ||
Comment 6•2 years ago
|
||
Updated•2 years ago
|
Assignee | ||
Comment 7•2 years ago
|
||
I think my patch here reflects why we don't go awry on this test case, but maybe I'm missing the forest for the trees. If we're running ExecutionRunnable::RunOnWorkletThread() on a thread that apparently isn't a worklet thread, that doesn't sound good. Maybe some error condition should have been detected earlier and bailed out?
Assignee | ||
Comment 8•2 years ago
|
||
It looks like the thread name for the thread we're calling ExecutionRunnable::RunOnWorkletThread() on is "GraphRunner".
Assignee | ||
Comment 9•2 years ago
|
||
Across all of the plain mochitests in dom/worklet/tests/, dom/worklet/tests/test_paintWorklet.html seems to be the only one where the name of the thread is "DOM Worklet" and not "GraphRunner", so I suppose that is normal.
Updated•2 years ago
|
Comment 10•2 years ago
|
||
Comment 11•2 years ago
|
||
Set release status flags based on info from the regressing bug 1612570
Updated•2 years ago
|
Comment 12•2 years ago
|
||
Be more precise in the types passed around to WorkletThread methods. r=karlt
https://hg.mozilla.org/integration/autoland/rev/19576e8a0027d40601ba7f985108d8ad66cdffa8
https://hg.mozilla.org/mozilla-central/rev/19576e8a0027
Assignee | ||
Comment 13•2 years ago
|
||
Comment on attachment 9314151 [details]
Bug 1811327 - Be more precise in the types passed around to WorkletThread methods.
ESR Uplift Approval Request
- If this is not a sec:{high,crit} bug, please state case for ESR consideration: This fixes up a minor bit of undefined behavior.
- User impact if declined: Undefined behavior could in theory lead to security problems if the compiler changes.
- Fix Landed on Version: 111
- Risk to taking this patch: Low
- Why is the change risky/not risky? (and alternatives if risky): This really just shuffles around some static casts to make them more accurate.
Comment 14•2 years ago
|
||
Comment on attachment 9314151 [details]
Bug 1811327 - Be more precise in the types passed around to WorkletThread methods.
Approved for 102.9esr.
Comment 15•2 years ago
|
||
uplift |
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Comment 16•2 years ago
|
||
Updated•2 years ago
|
Updated•1 year ago
|
Comment 17•8 months ago
|
||
Sorry for the burst of bugspam: filter on tinkling-glitter-filtrate
Adding reporter-external
keyword to security bugs found by non-employees for accounting reasons
Description
•