472619 - Assertion failure: JS_PROPERTY_CACHE(cx).disabled == fp->pcDisabledSave - js1_8/extensions/regress-452913.js

Status: RESOLVED WONTFIX

(Core :: JavaScript Engine, defect)

Description

[Bob Clary [:bc] (inactive)]

js1_8/extensions/regress-452913.js shell 

Assertion failure: JS_PROPERTY_CACHE(cx).disabled, at jsinterp.c:97

regressed (or uncovered) by bug 434837.

See also bug 462991.

Comment 1

[Bob Clary [:bc] (inactive)]

(In reply to comment #0)

> regressed (or uncovered) by bug 434837.

this is wrong, sorry. I'm not sure of the regressor at the moment.

Comment 2

[Samuel Sidler (old account; do not CC)]

If we regressed this during this cycle, we should block on it. Otherwise, we can take it in 1.9.0.7.

Comment 3

[Bob Clary [:bc] (inactive)]

the full assert is:

Assertion failure: JS_PROPERTY_CACHE(cx).disabled == fp->pcDisabledSave, at jsinterp.c:69q76

Comment 4

[Bob Clary [:bc] (inactive)]

looks like bug 322889 is the winner. The test wasn't added until 2008-11-21, but the first failure didn't appear until 2008-11-16. Even then it only occurred a dozen or so times out of hundreds of test runs. While trying to bisect it, the failure was very dependent on how well the objdir was clobbered between builds. The most reliable method was to just remove the objdir altogether.

Comment 5

[Bob Clary [:bc] (inactive)]

err, didn't appear until 2008-12-16

Comment 6

[Daniel Veditz [:dveditz]]

Since this has been broken the whole life of Firefox 3 we probably don't need to block a 3.0.x release on it, and will take it when it gets fixed on trunk/3.1

Or does this only happen on the 1.9.0 branch?

What's the security implication of this assertion?

Comment 7

[Bob Clary [:bc] (inactive)]

just 1.9.0

Comment 8

[Robert Sayre]

Removing blocking1.9.1 nom per comment 7

Comment 9

[Bob Clary [:bc] (inactive)]

dveditz: any reason to keep this private now that bug 452913 is open?

Comment 10

[Daniel Veditz [:dveditz]]

Never got an answer to my main question in comment 6, how bad is this as a potential security problem. If it is one then let's keep this private and think about making bug 452913 comment 44 private.

Comment 11

[Blake Kaplan (:mrbkap) (inactive)]

I'm not really sure what the answer is -- it *seems* like this could lead to two objects with different shapes seeming to have the same shape, which could lead to [sg:crit] bugs, but I don't know if that's possible in practice. Brendan?

Comment 12

[Brandon Sterne (:bsterne)]

Since this one's been tough to triage and there is the potential for critical exploits per comment 11, I'm putting this one on our Top Security Bugs list.  Please treat this as a priority.

Comment 13

[Brendan Eich [:brendan]]

This is not exploitable -- the bug is that rt->shapeGen overflows so js_GC leaves the property cache disabled. It can't be reenabled, but the assertion botching is the only effect. Suggest WONTFIX, or a targeted backport of changes from bugs such as bug 419091.

/be

Comment 14

[Brendan Eich [:brendan]]

The patch for bug 487039 removed JSStackFrame::pcDisabledSave and fixed real bugs which are unpatched in 1.9.0.x -- I'm making this bug depend on that one pending a better idea.

/be

Comment 15

[Brendan Eich [:brendan]]

Igor, should patches be back-ported? Sayre may have an opinion too. This is one of the bugs in bsterne's automated report, but it is not obviously exploitable and it is not hard to fix.

/be

Comment 16

[Igor Bukanov]

We should try to backport the bug 487039. Surely the assert in this bug is not exploitable, but the bug 487039 could be.

Comment 17

[Robert Sayre]

(In reply to comment #16)
> We should try to backport the bug 487039. Surely the assert in this bug is not
> exploitable, but the bug 487039 could be.

assigning to igor for the backport.

Comment 18

[Igor Bukanov]

The bug is on no longer supported branch.