Assertion failure: iter->done(), at js/src/jit/JitFrames.cpp:695
Categories
(Core :: JavaScript: WebAssembly, defect, P1)
Tracking
()
People
(Reporter: sm-bugs, Assigned: jandem)
References
(Blocks 2 open bugs)
Details
(4 keywords, Whiteboard: [adv-main129+][adv-ESR115.14+][adv-ESR128.1+])
Attachments
(5 files)
|
308 bytes,
application/x-javascript
|
Details | |
|
48 bytes,
text/x-phabricator-request
|
dmeehan
:
approval-mozilla-beta+
dmeehan
:
approval-mozilla-esr128+
dveditz
:
sec-approval+
|
Details | Review |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
dmeehan
:
approval-mozilla-esr115+
|
Details | Review |
|
125 bytes,
text/plain
|
Details |
Steps to reproduce:
Checkout commit 9fcc11127fbfbdc88cbf37489dac90542e141c77 and invoke the js shell as follows:
js --fuzzing-safe <test-case>
Actual results:
Assertion failure: iter->done(), at js/src/jit/JitFrames.cpp:695
Updated•1 year ago
|
| Assignee | ||
Comment 1•1 year ago
|
||
We have a Wasm => JS JIT call and the JS code throws an exception. The Wasm code catches the exception but it looks like the exception handler code then doesn't expect that to happen (it's not just the assertion, the trampoline code calling the exception handler also seems incomplete). A bit surprising because I'd have expected tests, fuzzers, or websites to have hit this by now.
var throwExc = false;
var e = {m: {foreign() {
if (throwExc) {
throw new TypeError("hi");
}
}}};
var bin = wasmTextToBinary(`(module(import "m" "foreign" (func $foreign))(func (export "f") try(call $foreign)end))`);
var mod = new WebAssembly.Module(bin);
var inst = new WebAssembly.Instance(mod, e);
for (var i = 0; i < 20; i++) {
inst.exports.f();
}
throwExc = true;
inst.exports.f();
| Assignee | ||
Updated•1 year ago
|
| Assignee | ||
Comment 2•1 year ago
|
||
Phabricator patches are not synced to bugzilla atm, so:
https://phabricator.services.mozilla.com/D214959
https://phabricator.services.mozilla.com/D214960
Comment 3•1 year ago
|
||
I'm not able to view that Phabricator link, so maybe the permissions are off somehow.
How bad of a security issue is this? I can't tell from the comments in this bug so far. Thanks.
| Assignee | ||
Comment 4•1 year ago
|
||
| Assignee | ||
Comment 5•1 year ago
|
||
Comment 6•1 year ago
|
||
I am able to view the Phabricator link now. It looks like phab-bot just updated it.
| Assignee | ||
Comment 7•1 year ago
|
||
(In reply to Andrew McCreight [:mccr8] from comment #3)
How bad of a security issue is this? I can't tell from the comments in this bug so far. Thanks.
I'll say sec-high because we jump to a Wasm catch handler with garbage in the instance register. A local non-debug build crashes like this:
0x852ac69d101: mov 0x48(%r14),%rcx
=> 0x852ac69d105: testl $0x1,(%rcx)
(rr) p/x $rcx
$1 = 0xe5e5e5e5e5e5e5e5
Updated•1 year ago
|
Updated•1 year ago
|
| Assignee | ||
Comment 8•1 year ago
|
||
Comment on attachment 9409677 [details]
Bug 1904644 - Share more exception handling code. r?rhunt!
Security Approval Request
- How easily could an exploit be constructed based on the patch?: It's not super easy but probably also not very difficult.
- Do comments in the patch, the check-in comment, or tests included in the patch paint a bulls-eye on the security problem?: No
- Which branches (beta, release, and/or ESR) are affected by this flaw, and do the release status flags reflect this affected/unaffected state correctly?: All
- If not all supported branches, which bug introduced the flaw?: None
- Do you have backports for the affected branches?: Yes
- If not, how different, hard to create, and risky will they be?: Should apply or be easy to backport.
- How likely is this patch to cause regressions; how much testing does it need?: Not very likely, but exception handling is complicated.
- Is the patch ready to land after security approval is given?: Yes
- Is Android affected?: Yes
Comment 9•1 year ago
|
||
It's too late to get this into Fx128, and it's a bad candidate to be a "ride-along" in the mid-cycle point release because we don't schedule a mid-cycle release for the ESR branch(es). We should wait until after the release to land this.
Updated•1 year ago
|
Comment 10•1 year ago
|
||
Comment on attachment 9409677 [details]
Bug 1904644 - Share more exception handling code. r?rhunt!
sec-approval+ = dveditz
please request beta uplift, and esr after we get some nightly/beta confidence
Updated•1 year ago
|
Updated•1 year ago
|
| Assignee | ||
Updated•1 year ago
|
Comment 11•1 year ago
|
||
Comment 12•1 year ago
|
||
Comment 13•1 year ago
|
||
:jandem could you add beta, ESR115, and ESR128 uplift requests on this when ready?
| Assignee | ||
Comment 14•1 year ago
|
||
Comment on attachment 9409677 [details]
Bug 1904644 - Share more exception handling code. r?rhunt!
Beta/Release Uplift Approval Request
- User impact if declined: Security bugs, crashes.
- Is this code covered by automated tests?: Yes
- Has the fix been verified in Nightly?: Yes
- Needs manual test from QE?: No
- If yes, steps to reproduce:
- List of other uplifts needed: None
- Risk to taking this patch: Low
- Why is the change risky/not risky? (and alternatives if risky): Complicated code but changes are fairly straight-forward. The problematic case that's being fixed isn't used much in the wild at this point.
- String changes made/needed: N/A
- Is Android affected?: Yes
| Assignee | ||
Comment 15•1 year ago
|
||
I added the approval requests. This might not apply cleanly to the older branches - I can upload separate patches for these if it's an issue.
Comment 16•1 year ago
|
||
It'll need a bit of rebasing for ESR115. The other branches graft cleanly.
Comment 17•1 year ago
|
||
Comment on attachment 9409677 [details]
Bug 1904644 - Share more exception handling code. r?rhunt!
Approved for 129.0b7
Comment 18•1 year ago
|
||
| uplift | ||
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
| Assignee | ||
Comment 19•1 year ago
|
||
| Assignee | ||
Updated•1 year ago
|
| Assignee | ||
Comment 20•1 year ago
|
||
(In reply to Ryan VanderMeulen [:RyanVM] from comment #16)
It'll need a bit of rebasing for ESR115. The other branches graft cleanly.
I posted a patch for ESR115. Fortunately it was just a single minor conflict. I also verified the tests fail on ESR115 and are fixed by this patch.
Comment 21•1 year ago
|
||
Comment on attachment 9409677 [details]
Bug 1904644 - Share more exception handling code. r?rhunt!
Approved for 128.1esr.
Comment 22•1 year ago
|
||
| uplift | ||
Updated•1 year ago
|
Comment 23•1 year ago
|
||
Comment on attachment 9414107 [details]
Bug 1904644 - Share more exception handling code. r=rhunt!, a=dmeehan (ESR115)
Approved for 115.14esr
Comment 24•1 year ago
|
||
| uplift | ||
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Comment 25•1 year ago
|
||
Updated•1 year ago
|
Comment 26•1 year ago
|
||
2 months ago, dveditz placed a reminder on the bug using the whiteboard tag [reminder-test 2024-09-09] .
jandem, please refer to the original comment to better understand the reason for the reminder.
| Assignee | ||
Updated•1 year ago
|
Comment 27•1 year ago
|
||
Comment 28•1 year ago
|
||
Updated•8 months ago
|
Description
•