2008698 - (CVE-2026-24869) Tab crashes when moving many elements that are anchor positioned

Status: RESOLVED FIXED

(Core :: Layout: Scrolling and Overflow, defect)

Description

[Patrick Brosset <:pbro>]

This is a bit of an extreme use case, I'll admit, but nevertheless a crasher that should be fixed.

Version: 148.0a1 (2026-01-04) (aarch64)
OS: Windows 11

Steps:

1. Go to https://patrickbrosset.com/articles/2026-01-06-fun-with-the-web/
2. Scroll down almost to the end, until you see the last demo on this page (alternatively, search for "one last silly experiment before I wrap this up" on the page, the demo is right below it).
3. In the demo rectangle, click an hold the red popup titled Confirm (move me) and then drag it around.

Actual: after some time dragging it around, the tab crashes.
Expected: it shouldn't crash.

To see the source code:

• CSS: https://patrickbrosset.com/assets/fun-with-the-web-embedded-demos/popup-hell.css
• JS: https://patrickbrosset.com/assets/fun-with-the-web-embedded-demos/popup-hell.js

Comment 1

[Hiroyuki Ikezoe (:hiro)]

Here is a crash report; https://crash-stats.mozilla.org/report/index/48da4669-b770-44b3-a561-63c040260106

Comment 2

[Hiroyuki Ikezoe (:hiro)]

Thank you Patrick for reporting this crash!

Comment 3

[Timothy Nikkel (:tnikkel)]

We get a reference to an entry in the hashtable here
https://searchfox.org/firefox-main/rev/33bba5cfe4a89dda0ee07fa9fbac578353713fd3/layout/base/DisplayPortUtils.cpp#1401

and then we call ShouldAsyncScrollWithAnchorNotCached
https://searchfox.org/firefox-main/rev/33bba5cfe4a89dda0ee07fa9fbac578353713fd3/layout/base/DisplayPortUtils.cpp#1408

which won't use the hashtable for the current frame, but it will walk the frame tree and can modify the hashtable with the key as a different frame, and this will invalidate the reference we are holding to the hashtable entry. We knew about this problem when reviewing this code, but this escaped us at the time, I guess because the code structure unintentionally hides it.

I think we will have to do two hash table lookups, one to check if its present and then another one to store the result if it was not present. Unless Hiro has a better idea.

Comment 4

[BugBot [:suhaib / :marco]]

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

Comment 5

[Timothy Nikkel (:tnikkel)]

Got a fix, just working on finalizing a test.

I think this is probably too late to get this in to 147. That should be okay, it looks like all the crashes in crash stats for this are likely due to this one extreme example, they all happened in the last day, and the ones that have a url point to this testcase.

Comment 6

[Timothy Nikkel (:tnikkel)]

Actually, I think this could potentially be a sec issue.

Comment 7

[Timothy Nikkel (:tnikkel)]

Attachment: (secure)

Comment 8

[Timothy Nikkel (:tnikkel)]

I think changing the hashtable while holding an entry is generally sec-high, please adjust if I'm mistaken.

Comment 9

[Timothy Nikkel (:tnikkel)]

Attachment: (secure)

Comment 10

[Timothy Nikkel (:tnikkel)]

Comment on attachment 9536033 [details]
(secure)

Security Approval Request

• How easily could an exploit be constructed based on the patch?: pretty easily? not hard to tell that the issue is chained anchors, with a little tinkering a testcase can be generated with a long chain of anchors and then you have a use-after-free to build on. the existing comments in the code already point out this issue we just didn't realize we were still not doing it properly. this patch makes the comment more explicit on the problem, i can land the comment change later if we need
• Do comments in the patch, the check-in comment, or tests included in the patch paint a bulls-eye on the security problem?: Yes
• Which branches (beta, release, and/or ESR) are affected by this flaw, and do the release status flags reflect this affected/unaffected state correctly?: 147 and newer
• If not all supported branches, which bug introduced the flaw?: Bug 2003843
• Do you have backports for the affected branches?: Yes
• If not, how different, hard to create, and risky will they be?:
• How likely is this patch to cause regressions; how much testing does it need?: not likely, automated tests are sufficient
• Is the patch ready to land after security approval is given?: Yes
• Is Android affected?: Yes

Comment 11

[Daniel Holbert [:dholbert]]

Given comment 6 through comment 10, this might be worth getting into 147 (maybe in a dot release if it can't make the initial release, given that we're in RC week).

Comment 12

[Timothy Nikkel (:tnikkel)]

Yeah, I talked to RyanVM (managing 147). He said proceed to normal security landing procedure and see where we that gets us, so I've requested approval to land.

Comment 13

[Daniel Veditz [:dveditz]]

Comment on attachment 9536033 [details]
(secure)

sec-approval+ for the patch. I'm assuming RyanVM will OK this for the 147 dot release. Land the tests separately after 2026-03-01.

Comment 14

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/51cc426eea79
https://hg.mozilla.org/integration/autoland/rev/f4d19973ebb4
Don't hold an entry in the AsyncScrollsWithAnchorHashmap hash table while we can modify the hashtable elsewhere. r=hiro,layout-reviewers

Comment 15

[Timothy Nikkel (:tnikkel)]

I tried to do a beta uplift request but it errored out, not sure if I need to wait for this to merge to central maybe.

Comment 16

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

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

Comment 17

[Timothy Nikkel (:tnikkel)]

Tried again to uplift to release this time, same error.

I don't think it's merge conflicts, I tried applying to beta locally and there was no problem (no fuzz etc needed).

Comment 18

[Timothy Nikkel (:tnikkel)]

Attachment: (secure)

Comment 19

[Phabricator Automation]

firefox-release Uplift Approval Request

• User impact if declined: sec-high
• Code covered by automated testing: yes
• Fix verified in Nightly: yes
• Needs manual QE test: no
• Steps to reproduce for manual QE testing:
• Risk associated with taking this patch: low
• Explanation of risk level: instead of holding a hash table entry while we modify the table we do two hash table lookups
• String changes made/needed: none
• Is Android affected?: yes

Comment 20

[Daniel Holbert [:dholbert]]

Yeah, something looks pretty busted there... the lando page's uplift-request UI says:

Aborting, could not apply patch buffer for 278067.
Error running git command; sanitised_command=['git', 'cherry-pick', '9f063881687691e1b3bf9162523f48366edafd7b'], path='/files/repos/firefox-release', fatal: bad object 9f063881687691e1b3bf9162523f48366edafd7b

So it looks like our uplift automation is trying to run git cherry-pick 9f063881687691e1b3bf9162523f48366edafd7b.

And the commit-ID string 9f063881687691e1b3bf9162523f48366edafd7b appears to be bogus, i.e. not a valid commit. I believe that git cherry-pick parameter is supposed to be the git commit ID for the patch that we want to apply. And in this case, the correct commit ID would be 51cc426eea79efa05a86e08a216119e387ac3f45 (the extended version of the hash in comment 14's github URL).

I have no idea where 9f063881687691e1b3bf9162523f48366edafd7b is coming from; it's not any commit that exists on https://github.com/mozilla-firefox/firefox/ (checking for it leads to a 404).

Comment 21

[Timothy Nikkel (:tnikkel)]

Bug 2009220 was filed for uplift failure in case anyone is looking for that.

Comment 22

[Daniel Holbert [:dholbert]]

Aha, maybe you got it working?

I see we have https://phabricator.services.mozilla.com/D278379 associated with this bug now, pending approval from release-managers, so maybe that's the successfully-generated uplift request.

[edit: looks like you did get it working; I now see comment 19 and comment 21; thanks.]

Comment 23

[Timothy Nikkel (:tnikkel)]

(In reply to Daniel Holbert [:dholbert] from comment #22)

Aha, maybe you got it working?

I see we have https://phabricator.services.mozilla.com/D278379 associated with this bug now, pending approval from release-managers, so maybe that's the successfully-generated uplift request.

I did the manual process of applying a patch to firefox release on my machine and then using moz-phab uplift. This is the fallback approach when things don't apply cleanly (or there are other issues).

Comment 24

[BugBot [:suhaib / :marco]]

The patch landed in nightly and beta is affected.
:tnikkel, 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-firefox147 to wontfix.

For more information, please visit BugBot documentation.

Comment 25

[Pulsebot]

https://github.com/mozilla-firefox/firefox/commit/d371c02b3e9e
https://hg.mozilla.org/releases/mozilla-release/rev/03c763255760

Comment 26

[Phabricator Automation]

Comment on attachment 9536040 [details]
(secure)

Revision D278073 was moved to bug 2020278. Setting attachment 9536040 [details] to obsolete.

Comment 27

[BugBot [:suhaib / :marco]]

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

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