1970438 - With self-hosted cache enabled, GC-UAF crash on a demo

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect, P2)

Description

[Mayank Bansal]

enable self-host cache
Go to this link
Click on play

AR: Crash.

I do not crash on a fresh profile, but repro consistently on my daily profile which has a bunch of addons. I tried disabling some, but couldnt find any pattern. Maybe their presence changes some timing or threshold and that causes crash?

Most of the generated crashes do not have appropriate symbol. Example: https://crash-stats.mozilla.org/report/index/5120a3d4-d57b-4054-b1b8-455340250604

Some Crashes do have known signatures :
https://crash-stats.mozilla.org/report/index/aef28a4e-6a80-4f6f-8ad8-4b4b10250604
https://crash-stats.mozilla.org/report/index/385fefa2-c7f3-43bb-8515-b46fe0250604

Comment 2

[BugBot [:suhaib / :marco]]

Set release status flags based on info from the regressing bug 1827914

:bthrall, since you are the author of the regressor, bug 1827914, could you take a look? Also, could you set the severity field?

For more information, please visit BugBot documentation.

Comment 3

[BugBot [:suhaib / :marco]]

The bug is linked to a topcrash signature, which matches the following criteria:

• Top 20 desktop browser crashes on release (startup)
• Top 20 desktop browser crashes on beta
• Top 10 content process crashes on release
• Top 10 AArch64 and ARM crashes on release (startup)

For more information, please visit BugBot documentation.

Comment 4

[Bryan Thrall [:bthrall]]

It looks like the crash signature is clashing with unrelated crashes, since bug 1827914 was only merged as of Firefox 140 and a lot of these crashes are happening on earlier versions.

Filtering the crash reports looking for the poison address 0x4b4b4b, which shows up in Mayank's crashes, only shows about 43 potential crashes.

Since this should only affect systems where self_hosted_cache is turned on (it is off by default), I think this shouldn't have a high severity right now.

Comment 5

[Mayank Bansal]

I am removing the crash signature and the top-crash keyword from this bug. The crash signature is a little generic now, so bmo conflates it with existing crashes. This bug is specific to enabling the selfhost cache.

Comment 6

[BugBot [:suhaib / :marco]]

Copying crash signatures from duplicate bugs.

Comment 7

[Mayank Bansal]

This is the latest crash report: https://crash-stats.mozilla.org/report/index/1e235022-d3be-419b-b8d5-9fca50250610#tab-bugzilla
Now the signature says [@ EnterJit ]

Comment 8

[BugBot [:suhaib / :marco]]

Set release status flags based on info from the regressing bug 1827914

Comment 9

[Mayank Bansal]

I got a crash with a different signature today : https://crash-stats.mozilla.org/report/index/f1c6846c-65e0-4db3-b04e-f64d80250729#tab-bugzilla but that was only once.
Then i got this: https://crash-stats.mozilla.org/report/index/9d6eaf0a-ab48-4c6a-8ce5-d6a420250729#tab-bugzilla

Comment 10

[Matthew Gaudet (he/him) [:mgaudet]]

This is insanely helpful. On my profile this crashes every time with a signature we've been seeking. I'm going to try and see if I can reproduce in an rr recording

Thank you very much Mayank.

Comment 11

[Matthew Gaudet (he/him) [:mgaudet]]

Here's the pernosco trace

Comment 12

[Iain Ireland [:iain]]

I nerd-sniped myself a bit on this.

I'm pretty sure that the problem here is the pre-barrier code here. It looks like it should work for realm-independent code, but to decide whether it can bake in a realm, it checks whether there's a compile realm set on the macroassembler, which is apparently still the case even though we're trying to generate realm-independent code.

We should probably ensure the compile-realm is null in this case.

Comment 13

[Mayank Bansal]

I saw this crash in my about:crashes: https://crash-stats.mozilla.org/report/index/05c8589b-0708-4c7c-969f-5cbc70250808#tab-details

No idea how/when it happened.

Comment 15

[BugBot [:suhaib / :marco]]

The severity field for this bug is set to S4. However, the following bug duplicate has higher severity:

• Bug 1981780: S3

:sdetar, could you consider increasing the severity of this bug to S3?

For more information, please visit BugBot documentation.

Comment 16

[Bryan Thrall [:bthrall]]

Attachment: (secure)

When a Realm is present, MacroAssembler::branchTestNeedsIncrementalBarrier()
bakes a pointer specific to the Realm's Zone into the bytecode, making it not
Realm-independent.

Comment 17

[Iain Ireland [:iain]]

This should probably be marked as security-sensitive, since it's a UAF. It's quite slow/difficult to reproduce even with testing functions, and relies on precise timing, so I'll mark it as sec-moderate. Note that this feature is disabled in all releases.

Comment 18

[BugBot [:suhaib / :marco]]

Copying crash signatures from duplicate bugs.

Comment 20

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/e0e8f7b4c357
https://hg.mozilla.org/integration/autoland/rev/f47783e1bc58
Compile with nullptr Realm for realmIndependentJitCode r=iain

Comment 21

[Donal Meehan [:dmeehan]]

https://hg.mozilla.org/mozilla-central/rev/f47783e1bc58

Comment 22

[Daniel Veditz [:dveditz]]

Bug Bounty note: We are not changing the bounty we have already awarded on this bug, but we do need to note that in retrospect we realized this bug is technically ineligible for a bounty. Features have to be enabled by default in at least Nightly to be eligible.

We note this so you don't have the wrong expectations about future bounties for self-hosted cache or other disabled features.