copy SVGSVGElement.currentTranslate if we insert it into an SVGPointList

RESOLVED FIXED in Firefox 32



5 years ago
3 years ago


(Reporter: heycam, Assigned: heycam)



Bug Flags:
in-testsuite +
qe-verify -

Firefox Tracking Flags

(firefox31 wontfix, firefox32 fixed, firefox33 fixed, firefox34 fixed, firefox-esr24 unaffected, firefox-esr31 fixed, b2g-v1.3 unaffected, b2g-v1.3T unaffected, b2g-v1.4 unaffected, b2g-v2.0 fixed, b2g-v2.1 fixed)


(Whiteboard: [adv-main32-][adv-esr32-] hidden while bug 1018524 is)


(2 attachments)

Created attachment 8458436 [details] [diff] [review]

While looking at bug 1018524 I noticed that we also don't make a copy of SVGSVGElement.currentTranslate, an SVGPoint, if we try to insert it into a list.  I don't think this results in anything harmful (we don't have a tearoff table for SVGPoints) other than an odd coupling of currentTranslate and say a <polyline points=""> attribute, but I'm hiding this bug while bug 1018524 is still hidden.

I've changed Clone to Copy, to match the naming on SVGLengthList, and changed it to always return an SVGDOMPoint as it looks like the return-the-same-concrete-class behaviour isn't being relied upon.
Attachment #8458436 - Flags: review?(longsonr)
Attachment #8458436 - Flags: review?(longsonr) → review+
Created attachment 8459098 [details] [diff] [review]

Meant to include this test too.
Attachment #8459098 - Flags: review?(longsonr)
Attachment #8459098 - Flags: review?(longsonr) → review+
Keywords: sec-other
Whiteboard: hidden while bug 1018524 is
Landed at longsonr's request in bug 1018524. Should we backport this to the release branches as well or is it OK landing on trunk only?
Flags: needinfo?(longsonr)
Flags: in-testsuite+
It wants landing everywhere we land bug 1018524 it's potentially a similar hole although we've no known exploit so if you know about one (and everyone does now) you just might be able to use that knowledge here.
Flags: needinfo?(longsonr)
Comment on attachment 8458436 [details] [diff] [review]

Approval Request Comment
[Feature/regressing bug #]: bug 886416 (31+)
[User impact if declined]: see comment 3
[Describe test coverage new/current, TBPL]: includes a test
[Risks and why]: low
[String/UUID change made/needed]: none
Attachment #8458436 - Flags: approval-mozilla-esr31?
Attachment #8458436 - Flags: approval-mozilla-beta?
Attachment #8458436 - Flags: approval-mozilla-aurora?
Given that this is rated sec-other, let's let this land on m-c before uplift.
Last Resolved: 5 years ago
status-firefox34: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla34
status-firefox31: --- → wontfix
status-firefox32: --- → affected
status-firefox33: --- → affected
status-firefox-esr31: --- → affected
Attachment #8458436 - Flags: approval-mozilla-esr31?
Attachment #8458436 - Flags: approval-mozilla-esr31+
Attachment #8458436 - Flags: approval-mozilla-beta?
Attachment #8458436 - Flags: approval-mozilla-beta+
Attachment #8458436 - Flags: approval-mozilla-aurora?
Attachment #8458436 - Flags: approval-mozilla-aurora+
status-b2g-v1.3: --- → unaffected
status-b2g-v1.3T: --- → unaffected
status-b2g-v1.4: --- → unaffected
status-b2g-v2.0: --- → affected
status-b2g-v2.1: --- → fixed
status-firefox32: affected → fixed
status-firefox33: affected → fixed
status-firefox-esr24: --- → unaffected
status-firefox-esr31: affected → fixed
There's no poc code or an exploitable bug that can be used for testing and verification. If there's something QE can do to test/verify this issue, please let us know and needinfo! Marking this as qe-verify- for the time being. (also as per comment #3, we currently don't have a known exploit)
Flags: qe-verify-
Whiteboard: hidden while bug 1018524 is → [adv-main32-][adv-esr32-] hidden while bug 1018524 is


3 years ago
Group: core-security → core-security-release
Group: core-security-release
You need to log in before you can comment on or make changes to this bug.