Last Comment Bug 711963 - Crash [@ @0x0 | nsSVGTextFrame::GetCanvasTM]
: Crash [@ @0x0 | nsSVGTextFrame::GetCanvasTM]
Status: RESOLVED DUPLICATE of bug 704706
[sg:dupe 704706]
: crash, regression, testcase
Product: Core
Classification: Components
Component: SVG (show other bugs)
: Other Branch
: All Linux
: -- critical (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
:
Mentors:
Depends on:
Blocks: langfuzz
  Show dependency treegraph
 
Reported: 2011-12-19 06:14 PST by Christian Holler (:decoder)
Modified: 2012-04-10 21:20 PDT (History)
5 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
unaffected
unaffected
+
fixed
+
fixed
unaffected
unaffected


Attachments

Description Christian Holler (:decoder) 2011-12-19 06:14:22 PST
This bug was filed from the Socorro interface and is 
report bp-c700f28a-c89e-44f2-b00e-2264a2111219 .
============================================================= 

The following SVG crashes Firefox Nightly (Build ID 20111218031140):


<svg xmlns="http://www.w3.org/2000/svg">
  <filter id="f_calcMode_linear_to" x="0%" y="0%" width="100%" height="100%">
    <feComponentTransfer>
      <feFuncR type="table" tableValues="0 2 2 0"/><text id="b">Text B</text></feComponentTransfer>
  </filter>
  <filter id="f_calcMode_discrete" x="0%" y="0%" width="100%" height="100%">
    <feComponentTransfer>
    </feComponentTransfer>
  </filter>
</svg>


Assuming sg:critical per severity rating guide, but I'm wondering why executing NULL should be relevant in a remote situation (it is under Windows when conducting local attacks but remote processes usually don't have this address mapped).
Comment 1 Daniel Veditz [:dveditz] 2011-12-22 13:24:39 PST
If we can prove that it's always EITHER a valid address OR null then it wouldn't be vulnerable, but the fact that our object is unexpectedly gone may mean we can't prove that. This testcase may always result in null, but until we know the cause we don't know if a slightly different one could end up with a different result.
Comment 2 Daniel Veditz [:dveditz] 2011-12-22 13:36:56 PST
I do not see a crash in Firefox 9 or 10a2.
Comment 3 Robert Longson 2011-12-22 14:36:07 PST
Didn't bug 704706 fix this? Are we getting crashes from builds with that patch in? If not this is a duplicate of that.
Comment 4 Gary Kwong [:gkw] [:nth10sd] 2011-12-22 15:06:12 PST
(In reply to Robert Longson from comment #3)
> Didn't bug 704706 fix this? Are we getting crashes from builds with that
> patch in? If not this is a duplicate of that.

Possibly so, I was testing with Dec 19, 2011 Mac nightly which crashed, and Dec 22, 2011 Mac nightly didn't.
Comment 5 Robert Longson 2011-12-22 15:22:12 PST
The code change in that bug is designed to cover this case so if we're not getting crashes post that landing then this is a duplicate.
Comment 6 Gary Kwong [:gkw] [:nth10sd] 2011-12-22 15:23:58 PST
And as per Jesse mentions in bug 704706 comment 0, it may indeed be a regression from the last few days prior to Nov 22, 2011, or possibly bug 696078.
Comment 7 Gary Kwong [:gkw] [:nth10sd] 2011-12-22 15:24:26 PST
Duping per comment 5.

*** This bug has been marked as a duplicate of bug 704706 ***
Comment 8 Robert Longson 2011-12-22 15:41:13 PST
(In reply to Gary Kwong [:gkw, :nth10sd] from comment #6)
> And as per Jesse mentions in bug 704706 comment 0, it may indeed be a
> regression from the last few days prior to Nov 22, 2011, or possibly bug
> 696078.

Jesse was spot on, bug 696078 was the cause.

Note You need to log in before you can comment on or make changes to this bug.