Closed
Bug 475185
Opened 15 years ago
Closed 15 years ago
Crash [@ js_ValueToString] calling DOM setter function directly with no arguments
Categories
(Core :: XPConnect, defect, P1)
Core
XPConnect
Tracking
()
RESOLVED
FIXED
mozilla1.9.1b3
People
(Reporter: jruderman, Assigned: mrbkap)
References
Details
(4 keywords, Whiteboard: [sg:critical?])
Crash Data
Attachments
(3 files)
195 bytes,
text/html
|
Details | |
953 bytes,
patch
|
jorendorff
:
review+
brendan
:
superreview+
|
Details | Diff | Splinter Review |
953 bytes,
patch
|
Details | Diff | Splinter Review |
Crashes trying to dereference 0xdadadad8.
Flags: blocking1.9.1?
Reporter | ||
Updated•15 years ago
|
Whiteboard: [sg:critical?]
Assignee | ||
Comment 1•15 years ago
|
||
I always forget that fast natives don't enforce minargs.
Assignee: nobody → mrbkap
Status: NEW → ASSIGNED
Attachment #358639 -
Flags: superreview?(brendan)
Attachment #358639 -
Flags: review?(jorendorff)
Updated•15 years ago
|
OS: Mac OS X → All
Hardware: x86 → All
Comment 2•15 years ago
|
||
Comment on attachment 358639 [details] [diff] [review] Fix That's why I initially made JSFastNatives enforce minargs -- phear of phorgetting (myself or anyone, really). No good way to automate assertion-based checking, alas. Maybe a static analysis? /be
Attachment #358639 -
Flags: superreview?(brendan) → superreview+
Comment 3•15 years ago
|
||
We need this for beta3 if we want to take the fix for bug 462428, which we do.
Flags: blocking1.9.1? → blocking1.9.1+
Priority: -- → P1
Target Milestone: --- → mozilla1.9.1b3
Comment 4•15 years ago
|
||
Comment on attachment 358639 [details] [diff] [review] Fix totally
Attachment #358639 -
Flags: review?(jorendorff) → review+
Assignee | ||
Comment 5•15 years ago
|
||
Here's an automated test for whenever we check in automated tests for security bugs.
Assignee | ||
Updated•15 years ago
|
Flags: in-testsuite?
Assignee | ||
Comment 6•15 years ago
|
||
http://hg.mozilla.org/mozilla-central/rev/0ca5fbbf83dc
Status: ASSIGNED → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 7•15 years ago
|
||
http://hg.mozilla.org/releases/mozilla-1.9.1/rev/e70d601d05d3
Keywords: fixed1.9.1
Comment 8•15 years ago
|
||
Surely it's not necessary for a bug that was only in place for a bare handful of days? One thing if it made it into a release (full, alpha, beta, RC), at which point I think you wait through the first fixed release before adding, but a run-of-the-mill nightly is a completely different thing.
You don't think it's necessary to check in a regression test for a bug that we only had briefly? I don't think it matters whether we caught it quickly the first time; we don't want to have to worry about *not* catching it if we regress it later on branch or trunk.
Comment 10•15 years ago
|
||
That was in response to comment 5's "for whenever we check in automated tests for security bugs", which I was arguing should be immediately (or at best no longer than a week later) for a bug present for so short a time in nightlies only.
Ah, sorry, didn't understand the antecedent of "it". Agreed, get it landed if we confirm that it doesn't affect any releases.
Comment 12•15 years ago
|
||
Regression test is ok, but it'll probably never fail again -- whereas there could be other fast natives that fall into the no-minargs trap -- or already have. Thus the static analysis hope. Jason, any thoughts? /be
Assignee | ||
Comment 13•15 years ago
|
||
The crashtest is checked in (http://hg.mozilla.org/mozilla-central/rev/d936f7070bd5).
Flags: in-testsuite? → in-testsuite+
Reporter | ||
Updated•15 years ago
|
Group: core-security
Comment 14•15 years ago
|
||
verified fixed on the 1.9.1 branch using Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20090211 Shiretoko/3.1b3pre and Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b3pre) Gecko/20090211 Shiretoko/3.1b3pre. I verified using the testcase in the bug.
Keywords: fixed1.9.1 → verified1.9.1
Updated•15 years ago
|
Flags: wanted1.9.0.x-
Updated•13 years ago
|
Crash Signature: [@ js_ValueToString]
You need to log in
before you can comment on or make changes to this bug.
Description
•