| Summary: | brw_fs.cpp:1466: bool fs_visitor::remove_dead_constants(): Assertion `constant_nr < (int)c->prog_data.nr_params | ||
|---|---|---|---|
| Product: | Mesa | Reporter: | fjhenigman <fjhmesabug> |
| Component: | Drivers/DRI/i965 | Assignee: | fjhenigman <fjhmesabug> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | medium | CC: | bjacob, eric, huzaifas, marchesin |
| Version: | git | ||
| Hardware: | x86-64 (AMD64) | ||
| OS: | Linux (All) | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Attachments: |
piglit shader_runner file containing problem shaders
fix updated fix |
||
Created attachment 73167 [details] [review] fix I think the problem is that after loop unrolling there's an out-of-bounds array access which fs_visitor::remove_dead_constants() does not expect so it hits an assert.
There is a check for out-of-bounds array access before this point, but I guess only before the shader code is transformed.
The patch changes the assertion failure to a compilation failure.
It also sets params_remap to NULL in the fs_visitor constructor since otherwise it seems the assert at brw_fs.cpp:1504 ("should have been generated in the 8-wide pass") could be testing an uninitialized value.
We have assigned CVE-2013-1872 to this security flaw. I am aware that the easiest way to exploit this is via a browser using webgl. Though mozilla and google have assigned CVEs, but that is because they impact the browser. The above CVE is assigned for its impact on MESA as shipped independently. Is there a un-embargo date for this flaw? Given that a piglit test reproducing this bug was sent out, is there a reason for this bug report to be marked secret? It's why I haven't looked at the fix for it. Only people in mesa security can alter the flag. So it's going to stay that way until someone from that group changes it. It seems i can alter the flag as well (not that i want to). The Bigger question here is can we consider this flaw to be public?, given that Mozilla and Google have published advisories about this flaw affecting their product? http://www.mozilla.org/security/announce/2013/mfsa2013-35.html Given that a work-around for this bug was rolled out in Firefox 20 (and separately, in Firefox ESR), I have no issue with this bug being made public from a Mozilla perspective. I _believe_ that in Chromium the work-around is deployed since version 25 so there should be no issue from the Chromium side either, but I'm not authoritative on this. I do not know the complete list of WebGL-supporting browsers that may run into this driver bug. Created attachment 79636 [details] [review] updated fix this fix checks for < 0 values as well. the fix is incomplete
Okay this fix is incomplete, if you use negative constant numbers
"uniform vec4 uni[1];\n"
"void main()\n"
"{\n"
" vec4 c = vec4(0,0,0,0);\n"
" for (int ii = -11; ii < -9; ++ii) {\n"
" c += uni[ii];\n"
" }\n"
" gl_FragColor = vec4(c.r, c.g, c.b, 0);\n"
"}\n"
a shader like the above causes problems, granted the webgl engines might block that sort of thing, but we should fix it properly!
This approach of failing to compile was rejected: http://lists.freedesktop.org/archives/mesa-dev/2013-January/033659.html I intended to write a patch taking that objection into account but haven't done so yet. fixed in master. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.
Created attachment 73106 [details] piglit shader_runner file containing problem shaders assertion hit during shader linking piglit shader_runner file attached tested on sandy bridge / gen 6