[ANGLE] Assertion `typeName' failed // Parser Crash [@ TType::TType]

VERIFIED FIXED

Status

()

Core
Canvas: WebGL
--
critical
VERIFIED FIXED
6 years ago
5 years ago

People

(Reporter: decoder, Assigned: bjacob)

Tracking

(Blocks: 1 bug, {crash, testcase})

Trunk
x86_64
Linux
crash, testcase
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox8- wontfix, firefox9- wontfix, firefox10- wontfix, firefox11 verified, firefox12+ verified, firefox13 verified, firefox-esr1011+ verified, status1.9.2 unaffected)

Details

(Whiteboard: [sg:critical][qa!], crash signature)

Attachments

(2 attachments)

(Reporter)

Description

6 years ago
Created attachment 571323 [details]
Test case for browser

This bug was filed from the Socorro interface and is 
report bp-611f2a52-3fc5-4d96-8f62-67a322111102 .
============================================================= 

The attached WebGL testcase asserts in Firefox Nightly Debug (tested with mesa llvmpipe software rendering):

firefox: /builds/slave/m-cen-lnx64-dbg/build/gfx/angle/src/compiler/Types.h:209: const TString& TType::getTypeName() const: Assertion `typeName' failed.

Running in a release build, the test crashes at TType::TType (see crash report).

The test might require MOZ_GL_DEBUG=1.

This is another parser crash but not a null-deref according to the crash report. Marking this s-s until triaged and rated. Let me know if I shall report this to ANGLE or if you do so.
(Assignee)

Comment 1

6 years ago
oh, this one is very different from the others (bug 698963, bug 620222, bug 699015) and might be more serious. Not a null deref.
(Assignee)

Comment 2

6 years ago
No need for MOZ_GL_DEBUG to reproduce this.
(Assignee)

Comment 3

6 years ago
ANGLE security bug: http://code.google.com/p/angleproject/issues/detail?id=241
Whiteboard: [sg:critical]

Updated

6 years ago
status-firefox10: --- → affected
status-firefox11: --- → affected
status-firefox8: --- → wontfix
status-firefox9: --- → affected
tracking-firefox10: --- → +
tracking-firefox11: --- → +
tracking-firefox8: --- → -
tracking-firefox9: --- → +
Benoit, any idea what the timeline for getting a fix here, either cherry picked from Angle or through a new drop?
Assignee: nobody → bjacob
(Assignee)

Comment 5

6 years ago
I just upgraded ANGLE to r885 which includes deep changes in the ANGLE compiler.

I can't reproduce the crash anymore in today's Nightly on Linux x86_64. Can you still reproduce?
(Reporter)

Comment 6

6 years ago
I can still reproduce the crash using nightly on Linux x86_64 (build 2011-11-21): https://crash-stats.mozilla.com/report/index/bp-0548938d-5942-40fc-a1b6-572cf2111121
Benoit, looks like this still happens after the angle update. Can you investigate further? Thanks!
status-firefox9: affected → wontfix
tracking-firefox9: + → ---

Updated

5 years ago
tracking-firefox9: --- → -
Chistian can you check that this is still valid? I believe a new version of angle has landed again in since the last time this bug was touched.
(Reporter)

Comment 9

5 years ago
Still crashes on a recent nightly: bp-a0a9f4e4-63d7-4136-ae5e-5f4a42120110
status-firefox12: --- → affected
tracking-firefox12: --- → +
status1.9.2: --- → unaffected
status-firefox-esr10: --- → affected
status-firefox10: affected → wontfix
status-firefox13: --- → affected
Benoit, this was filed 4 months ago, we need to move forward here, either by fixing this problem, or something else if we can't fix this.
status-firefox11: affected → wontfix
tracking-firefox10: + → -
tracking-firefox11: + → -
I just pinged the bug @ANGLE. It's not clear whether it's been looked into.
If we want to fix this bug ourselves, we need a developer who knows how to debug a compiler that uses bison-generated code.
The crash I'm still able to reproduce is a null pointer deref:
https://crash-stats.mozilla.com/report/index/fe00b5ce-d353-441b-9176-ef0102120223

I can't reproduce anymore the non-null pointer deref from the original crash report.
In a debug build it's pretty what's happening:

#2  0x00007ffff7343d4d in __GI___assert_fail (
    assertion=0x7ffff5e697b4 "typeName", file=<optimized out>, line=211, 
    function=<optimized out>) at assert.c:81
#3  0x00007ffff54b693c in TType::getTypeName (this=0x7fffd0c00000)
    at /home/bjacob/mozilla-central/gfx/angle/src/compiler/Types.h:211

    const TString& getTypeName() const
    {
        assert(typeName);  // <-- line Types.h:211
        return *typeName;
    }

We could turn this into a clear non-security bug by making this assert stay in release builds.

Also, the shader source triggering this is:

"\ninvariant Vertex  , Tex    , notEqual    , tan        ;\n"
Created attachment 600176 [details] [diff] [review]
castrate angle bug 241 to guarantee it's a plain crash, nothing worse
Attachment #600176 - Flags: review?(jst)

Updated

5 years ago
Attachment #600176 - Flags: review?(jst) → review+
Landed on central, so this is no longer a serious security bug on central, but still a crash bug.

http://hg.mozilla.org/mozilla-central/rev/69255fe4cb94
Comment on attachment 600176 [details] [diff] [review]
castrate angle bug 241 to guarantee it's a plain crash, nothing worse

[Approval Request Comment]
Regression caused by (bug #): probably ever since we enabled WebGL
User impact if declined: potential heap corruption (this patch turns it into a plain 'innocuous' crash by abort())
Testing completed (on m-c, etc.): just landed on m-c
Risk to taking this patch (and alternatives if risky): No risk, trivial 1-line patch
String changes made by this patch: none
Attachment #600176 - Flags: approval-mozilla-beta?
Attachment #600176 - Flags: approval-mozilla-aurora?
Comment on attachment 600176 [details] [diff] [review]
castrate angle bug 241 to guarantee it's a plain crash, nothing worse

[Triage comment]
Looks good, low risk.  Please land this today (02/27/12) in time for tomorrow's go-to-build on beta5
Attachment #600176 - Flags: approval-mozilla-beta?
Attachment #600176 - Flags: approval-mozilla-beta+
Attachment #600176 - Flags: approval-mozilla-aurora?
Attachment #600176 - Flags: approval-mozilla-aurora+
status-firefox11: wontfix → affected
Transplanted comment 16 to mozilla-aurora and mozilla-beta:

hg transplant -s ../mozilla-central/ 69255fe4cb94

http://hg.mozilla.org/releases/mozilla-aurora/rev/fa54977e954e
http://hg.mozilla.org/releases/mozilla-beta/rev/42612e9b5e2c
Cloning bug to deal with the non-exploitable crash as a follow-up
Blocks: 731046
-> Fixed since mitigation landed on mozilla-central, mozilla-beta and mozilla-aurora.

esr10 is affected, waiting on tracking + flag for approval to land on esr10.
Status: NEW → RESOLVED
Last Resolved: 5 years ago
status-firefox11: affected → fixed
status-firefox12: affected → fixed
status-firefox13: affected → fixed
Resolution: --- → FIXED
tracking-firefox-esr10: --- → 11+
tracking-firefox11: - → ---
Comment on attachment 600176 [details] [diff] [review]
castrate angle bug 241 to guarantee it's a plain crash, nothing worse

[Triage Comment]
Approving taking this for esr10, please land asap as go-to-build is coming up on Friday March 1. See https://wiki.mozilla.org/Release_Management/ESR_Landing_Process for details on ESR landing process.
Attachment #600176 - Flags: approval-mozilla-esr10+
http://hg.mozilla.org/releases/mozilla-esr10/rev/9b4aa9c5f05d
(Assignee)

Updated

5 years ago
status-firefox-esr10: affected → fixed
Verified fixed on Firefox 10.0.3esr
status-firefox-esr10: fixed → verified
Whiteboard: [sg:critical] → [sg:critical][qa+]
Verified fixed in Firefox 11.0b6 (tried both build1 and debug build -- did not crash with the attached testcase).
status-firefox11: fixed → verified
(Reporter)

Comment 26

5 years ago
Verified that the crash is now a null-pointer crash on Nightly.
Status: RESOLVED → VERIFIED
Verified fixed on Firefox 12b4 and Aurora 13.0a2 2012-04-04
status-firefox12: fixed → verified
status-firefox13: fixed → verified
Whiteboard: [sg:critical][qa+] → [sg:critical][qa!]
Group: core-security
You need to log in before you can comment on or make changes to this bug.