Closed
Bug 1382829
Opened 7 years ago
Closed 7 years ago
Crash in CContext::ID3D11DeviceContext1_SetShaderResources_<T>
Categories
(Core :: Graphics, defect)
Tracking
()
RESOLVED
FIXED
mozilla56
Tracking | Status | |
---|---|---|
firefox-esr52 | --- | unaffected |
firefox54 | --- | unaffected |
firefox55 | --- | unaffected |
firefox56 | + | fixed |
People
(Reporter: mccr8, Assigned: dvander)
References
Details
(4 keywords)
Crash Data
Attachments
(1 file)
3.77 KB,
patch
|
bas.schouten
:
review+
|
Details | Diff | Splinter Review |
This bug was filed from the Socorro interface and is report bp-c9a2d8c5-60dd-4436-9602-cd4d60170720. ============================================================= 30 crashes with this signature, mostly on Nightly. 8 crashes are on the poison-looking value 0xffffffffe5e5e625, while the rest are on 0x0.
Reporter | ||
Comment 1•7 years ago
|
||
Maybe this is a regression from advanced layers?
Flags: needinfo?(dvander)
Assignee | ||
Comment 2•7 years ago
|
||
I think I know what's happening. Video uses 3 textures, but we're failing to create a shader resource view for the first or second. But we still tell D3D11 to bind 3 textures, so it's binding garbage slots in the array.
Assignee: nobody → dvander
Status: NEW → ASSIGNED
Flags: needinfo?(dvander)
Assignee | ||
Comment 3•7 years ago
|
||
This refactors SetPSTextures so every element of the StackArray is always set. Arguably StackArray should be initializing mData, but this is good practice anyway.
Attachment #8888543 -
Flags: review?(bas)
Reporter | ||
Comment 5•7 years ago
|
||
[Tracking Requested - why for this release]: sec-crit regression
status-firefox56:
--- → affected
tracking-firefox56:
--- → ?
Reporter | ||
Updated•7 years ago
|
status-firefox54:
--- → unaffected
status-firefox55:
--- → unaffected
status-firefox-esr52:
--- → unaffected
Updated•7 years ago
|
Attachment #8888543 -
Flags: review?(bas) → review+
Assignee | ||
Comment 8•7 years ago
|
||
Comment on attachment 8888543 [details] [diff] [review] bug1382829.patch [Security approval request comment] How easily could an exploit be constructed based on the patch? Not easily. Do comments in the patch, the check-in comment, or tests included in the patch paint a bulls-eye on the security problem? No. Which older supported branches are affected by this flaw? None. If not all supported branches, which bug introduced the flaw? Do you have backports for the affected branches? If not, how different, hard to create, and risky will they be? How likely is this patch to cause regressions; how much testing does it need? Unlikely, this is only exposed by OOM. Normal tests on inbound are enough.
Attachment #8888543 -
Flags: sec-approval?
Reporter | ||
Comment 9•7 years ago
|
||
If this only affects Nightly, it doesn't need sec-approval.
Comment 10•7 years ago
|
||
Comment on attachment 8888543 [details] [diff] [review] bug1382829.patch Clearing sec-approval. Just check it into trunk.
Attachment #8888543 -
Flags: sec-approval?
Comment 12•7 years ago
|
||
https://hg.mozilla.org/integration/mozilla-inbound/rev/8a86ac7188adb863a1dac349c0b31be4927adccf
Comment 13•7 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/8a86ac7188ad
Status: ASSIGNED → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Updated•7 years ago
|
Target Milestone: --- → mozilla56
Updated•7 years ago
|
Group: gfx-core-security → core-security-release
Updated•7 years ago
|
Group: core-security-release
You need to log in
before you can comment on or make changes to this bug.
Description
•