2009608 - (CVE-2026-2758) Crash [@ js::gc::PreWriteBarrierImpl]

Status: RESOLVED FIXED

(Core :: JavaScript: GC, defect, P1)

Description

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

Attachment: testcase

See attachment

(gdb) bt
#0  js::gc::PreWriteBarrierImpl (thing=0xef351e99030) at /home/msf2/trees/firefox/js/src/gc/Cell.h:532
#1  0x0000555557a2e92d in js::gc::PreWriteBarrier<JSObject> (thing=0xef351e00000) at /home/msf2/trees/firefox/js/src/gc/Cell.h:552
#2  js::InternalBarrierMethods<JSObject*, void>::preBarrier (v=0xef351e00000) at /home/msf2/trees/firefox/js/src/gc/Barrier.h:351
#3  js::WriteBarriered<JSObject*>::pre (this=0x7ffff5e59cd8) at /home/msf2/trees/firefox/js/src/gc/Barrier.h:519
#4  js::PreBarriered<JSObject*>::setUnchecked (this=0x7ffff5e59cd8, v=<optimized out>) at /home/msf2/trees/firefox/js/src/gc/Barrier.h:572
#5  js::PreBarriered<JSObject*>::operator= (this=0x7ffff5e59cd8, other=...) at /home/msf2/trees/firefox/js/src/gc/Barrier.h:563
/snip

059f94423945-596024
059f9442394566ff0be7439a15ee55703c5e0057 is the first interesting commit
commit 059f9442394566ff0be7439a15ee55703c5e0057
Author: Jon Coppeard
Date:   Wed Nov 12 15:18:01 2025 +0000

    Bug 1827612 - Remove stable hashing for WeakMap and rekey entries instead r=sfink

    This adds a vector of keys of entries where the key or value is in the nursery
    so that we can trace these at the start or minor GC. If the vector grows too
    large we sweep the whole map instead.

    This replaces the post barrier for WeakMap keys so the table now uses
    PreBarriered<Key> instead of HeapPtr<Key>.

    This doesn't provide much improvement to WeakMap.get performance on its own but
    it is a prerequisite for bug 1995021.

    Stable hashing is still used for WeakRef and FinalizationRegistry targets.

    Differential Revision: https://phabricator.services.mozilla.com/D270562

Run with --fuzzing-safe --no-threads --ion-eager, compile with AR=ar sh ~/trees/firefox/js/src/configure --enable-debug --enable-debug-symbols --with-ccache --enable-nspr-build --enable-ctypes --enable-gczeal --enable-rust-simd --disable-tests, tested on gh rev 64a19d6e96aa456e7947aa3f96b4cd8b54f97235.

Jon, is bug 1827612 a likely regressor?

Comment 1

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

Attachment: debug stack

Comment 2

[BugBot [:suhaib / :marco]]

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

Comment 3

[Jon Coppeard (:jonco)]

This goes back to bug 1269319.

Comment 4

[Jon Coppeard (:jonco)]

Attachment: (secure)

The problem here is that we use move assignment on a hash table entry that is
not live. Although all entries are constructed by HashTable::createTable, they
may subsequently be destroyed by HashTableEntry::destroyStoredT(). Therefore it
is not safe to call any methods on a non live entry.

This causes a problem for GC barrier wrappers which assume that the object
state is valid (and presumably anything that does more than just write the
assigned data into memory).

The fix is to construct a new entry in place.

Comment 5

[Andrew McCreight [:mccr8]]

This isn't directly a "use after free" but more like a "use after destructor", but that could steal lead to a UAF in the presence of raw pointers (something like a RefPtr would be fine because it would null out the reference in the destructor). Also of note that this is an issue in mfbt/HashTable.h so in theory it could be causing issues in other places, though it looks like this is only part of the rehashing infrastructure which I'd imagine is only used by the JS engine.

Comment 6

[Jon Coppeard (:jonco)]

Attachment: (secure)

Comment 7

[Jon Coppeard (:jonco)]

Comment on attachment 9536908 [details]
(secure)

Security Approval Request

• How easily could an exploit be constructed based on the patch?: Very difficult. It requires precisely timed OOM and GC to reproduce.
• 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?: Everything back to FF 49
• If not all supported branches, which bug introduced the flaw?: Bug 1269319
• Do you have backports for the affected branches?: No
• If not, how different, hard to create, and risky will they be?: Should be trivial.
• How likely is this patch to cause regressions; how much testing does it need?: This is a small and straightforward change to use placement new instead of swap on a location that may have been destructued. Placement new is already used elsewhere in this code to construct these objects in place.
• Is the patch ready to land after security approval is given?: Yes
• Is Android affected?: Yes

Comment 8

[Daniel Veditz [:dveditz]]

I'm going to add bug 1827612 back to the regression list (in addition to bug 1269319). The underlying flaw might be old, but the testcase in this bug is only able to trigger the flaw with the additional change in the more recent bug. Do we patch ESR-115? Ryan says "wontfix", but the patch looks pretty straightforward. What is the balance between 1) risk of the patch, 2) risk that the vulnerability could be triggered in ESR-115 without the changes made in bug 1827612. Or even how reachable is it from a web page in current builds without the control fuzzers can get using jsshell testing functions?

Comment 9

[Ryan VanderMeulen [:RyanVM]]

It also got rated sec-high afterwards. Definitely open to backporting to ESR115 if needed.

Comment 10

[Daniel Veditz [:dveditz]]

Comment on attachment 9536908 [details]
(secure)

sec-approval+ for landing in nightly and uplift to beta. Hold off on the test, of course.

Comment 11

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/f78480f4ede2
https://hg.mozilla.org/integration/autoland/rev/3f043963046d
Don't assign non-live hash table entry r=glandium

Comment 12

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

I think this landed?

https://github.com/mozilla-firefox/firefox/commit/f78480f4ede2
https://hg-edge.mozilla.org/mozilla-central/rev/3f043963046d

Comment 13

[BugBot [:suhaib / :marco]]

The patch landed in nightly and beta is affected.
:jonco, is this bug important enough to require an uplift?

• If yes, please nominate the patch for beta approval.
  • See https://wiki.mozilla.org/Release_Management/Requesting_an_Uplift for documentation on how to request an uplift.
• If no, please set status-firefox148 to wontfix.

For more information, please visit BugBot documentation.

Comment 14

[Donal Meehan [:dmeehan]]

:jonco, to add to Comment 13, please also add ESR115 and ESR140 uplift requests. It grafts cleanly for both ESR branches.

Comment 15

[Jon Coppeard (:jonco)]

(In reply to Daniel Veditz [:dveditz] from comment #8)

I'm going to add bug 1827612 back to the regression list (in addition to bug 1269319). The underlying flaw might be old, but the testcase in this bug is only able to trigger the flaw with the additional change in the more recent bug. Do we patch ESR-115? Ryan says "wontfix", but the patch looks pretty straightforward. What is the balance between 1) risk of the patch, 2) risk that the vulnerability could be triggered in ESR-115 without the changes made in bug 1827612. Or even how reachable is it from a web page in current builds without the control fuzzers can get using jsshell testing functions?

That's a good point. I don't know how easy this is to trigger without the changes in bug 1827612. Probably very difficult, but this code is used in many different places throughout SpiderMonkey.

Since the patch is simple and applies I'd probably err on the side of caution.

Comment 16

[Jon Coppeard (:jonco)]

Comment on attachment 9536908 [details]
(secure)

Beta/Release Uplift Approval Request

• User impact if declined/Reason for urgency: Possible crash / security vulnerability.
• 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): This is a simple change that has been on central for a week with no issues.
• String changes made/needed: None
• Is Android affected?: Yes

Comment 17

[Jon Coppeard (:jonco)]

Comment on attachment 9536908 [details]
(secure)

ESR Uplift Approval Request

• If this is not a sec:{high,crit} bug, please state case for ESR consideration: It's a sec-high bug.
• User impact if declined: Possible crash / security vulnerability.
• Fix Landed on Version: 148
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): This is a simple change that has been on central for a week with no issues.

Comment 18

[Donal Meehan [:dmeehan]]

Comment on attachment 9536908 [details]
(secure)

Approved for 148.0b5

Comment 19

[Pulsebot]

https://github.com/mozilla-firefox/firefox/commit/5348f5242579
https://hg.mozilla.org/releases/mozilla-beta/rev/27f67596df10

Comment 20

[Donal Meehan [:dmeehan]]

Comment on attachment 9536908 [details]
(secure)

Approved for 140.8esr

Comment 21

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-esr140/rev/548640de7c3f

Comment 22

[Donal Meehan [:dmeehan]]

Comment on attachment 9536908 [details]
(secure)

Approved for 115.33esr

Comment 23

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-esr115/rev/6920d3f39cba

Comment 24

[BugBot [:suhaib / :marco]]

3 months ago, dveditz placed a reminder on the bug using the whiteboard tag [reminder-test 2026-04-01] .

jonco, please refer to the original comment to better understand the reason for the reminder.

Comment 25

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/9ab026ded9f5
https://hg.mozilla.org/integration/autoland/rev/ce27a9881bda
Add test case r=spidermonkey-reviewers,mgaudet

Comment 26

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

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