See upcoming testcase, which crashes Mozilla on load. Talkback ID: TB16137409Q HaveAutoWidth (Talbkack has become really short, lately) The testcase also crashes Mozilla1.7.12, so no (recent) regression.
Arrgh, the stack is bogus even in a debug build. This is certainly exploitable, at least writing to 0x0000002 seems like exploitable to me. We have a major error in the colgroup pseudo handling which yields a strange frame hierarchy cell - inner cell - cell. I need some time to come up with a fix. More than this I would like to move this bug after the OrderRowGroup removal which leads to the deleted object derefs. Martijn congratulations to your CVS privilege :-) , so its fair to assume that you have a build. If you find these bugs so quick you need to learn to classify them. The bogus talkback should have warned you.
(In reply to comment #2) > congratulations to your CVS privilege :-) Thanks :) > , so its fair to assume that you have a build. If you find these bugs so quick > you need to learn to classify them. The bogus talkback should have warned you. Well, I asked Boris some time ago, and he explicitly said not to file bugs as security sensitive (something with way too much security bugs already). I don't really know when a crash is exploitable. (normally, I don't fire up my debug build, maybe I should do that from now on with new crashes)
11 years ago
No, I am not asking to file every bug as security sensitive. But this bug causes already random function calls, it's not the typical already deleted stuff that I am used to. Launching a crash testcase in a debug build sounds like a good idea anyway, the stacktrace is more reliable than the talkback.
Created attachment 214778 [details] [diff] [review] patch The only question that this patch causes is why did I not close the door in bug 239294. Fear Uncertainty Doubt? Or did I not know Martijn at this time? Or did I try a minimal invasive patch?
Created attachment 215044 [details] [diff] [review] next rev. this is the next rev. still not *the* fix but closer to the issue.
11 years ago
Created attachment 215297 [details] [diff] [review] next rev
Comment on attachment 215297 [details] [diff] [review] next rev I _think_ I follow this. :( My eyes bleed, though. :(
fixed on trunk
Verified fixed using 2006-03-28 trunk build.
*** Bug 330015 has been marked as a duplicate of this bug. ***
this regressed the testcase in bug 325984
Is this exploitable? On a 184.108.40.206 windows debug build I crash in the nsMargin constructor reading from (0+offset) because mReflowState is null when nsBlockReflowState::BorderPadding() is called (the offset is the location of mComputedBorderPadding). Maybe some of these are uninitialized objects whose values would be non-null in a non-debug build, but in a debug Firefox 220.127.116.11 build this is pretty consistent. If you think it's exploitable we need a patch for the 1.8 and 1.8.0 branches. If it's not exploitable we can live with this low frequency crash (and should un-hide the bug).
Never mind: this fixes bug 330015 which is definitely operating on a deleted frame, so we do need it on the old branches.
Comment on attachment 215297 [details] [diff] [review] next rev a=jay for 1.8.0 checkin
Comment on attachment 215297 [details] [diff] [review] next rev 1.8.1 branch approval, a=jay for drivers
Comment on attachment 215297 [details] [diff] [review] next rev removing branch approvals from this patch in favor of the regression-fix cummulative patch in bug 333493
fixed on 1.8 branhc by the cumulative patch in bug 333493
fixed on 18.104.22.168
v.fixed on 1.8.0 branch with Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:22.214.171.124) Gecko/20060626 Firefox/126.96.36.199, no crash with testcase.
https://bugzilla.mozilla.org/attachment.cgi?id=214548&action=view ff2b2 winxp, linux no crash verified fixed 1.8
crash test landed http://hg.mozilla.org/mozilla-central/rev/fcb4bf8da2b8