2000597 - (CVE-2025-14860) AddressSanitizer: heap-use-after-free on mozilla::a11y::NotificationController::WillRefresh -> get

Status: VERIFIED FIXED

(Core :: Disability Access APIs, defect, P3)

Description

[Irvan Kurniawan [:sourc7]]

Attachment: testcase1.html

When repeatedly load invalid media src to <embed> element using requestIdleCallback, then after a click to the <embed> element, it able to crash with AddressSanitizer: heap-use-after-free on mozilla::a11y::NotificationController::WillRefresh

Tested on

• Firefox Beta ASan 146.0b4 (64-bit)
• Firefox Nightly ASan 147.0a1 (2025-11-17) (64-bit)

Steps to reproduce

1. Open Firefox Nightly or Firefox ASan Nightly
2. Make sure Accessibility set to true(in about:support)
3. Visit attached testcase1.html
4. Click on the <embed> media element
5. Firefox tab crashes with AddressSanitizer: heap-use-after-free on mozilla::a11y::NotificationController::WillRefresh

If it still doesn't crash, try clicking the <embed> media element multiple times.

When using mozregression, I found the crash is possible after commit
Bug 1997773 - Consider hiding the frame loader earlier in nsFrameLoader::Destroy

Comment 1

[Irvan Kurniawan [:sourc7]]

Attachment: asan-nightly.txt

Comment 2

[Irvan Kurniawan [:sourc7]]

This appears similar to my previously reported Bug 1709976, which required Accessibility Activated set to true (in about:support) and a mouse click to trigger the crash.

Comment 3

[Irvan Kurniawan [:sourc7]]

Attachment: log_minidump_SEGV_MAPERR.txt

Comment 4

[Irvan Kurniawan [:sourc7]]

Attachment: log_minidump_SI_KERNEL.txt

Comment 5

[Andrew McCreight [:mccr8]]

I haven't verified this myself, but I'm going to mark it sec-high assuming it is reasonably reproducible, as described.

Comment 6

[James Teh [:Jamie]]

I guess a11y::NotificationController::mPresShell died. What I don't understand is how that could happen while a11y::NotificationController is still registered as a refresh observer. Destroying the PresShell should destroy the DocAccessible, which should in turn destroy NotificationController, removing it as a refresh observer and nulling out its mPresShell.

Comment 7

[Irvan Kurniawan [:sourc7]]

Attachment: testcase2.single-click.html

Here I attached new testcase that reliably causes the tab to crash only after a single click on the <embed> element.

Comment 8

[Irvan Kurniawan [:sourc7]]

(In reply to Irvan Kurniawan [:sourc7] from comment #7)

Created attachment 9527382 [details]
testcase2.single-click.html

Here I attached new testcase that reliably causes the tab to crash only after a single click on the <embed> element.

When using Tab key to focus the <embed> element can also cause the tab to crash.

Comment 9

[Eitan Isaacson [:eeejay]]

When the DocAccessible is destroyed, following the destruction of the PresShell, we call FocusManager::ActiveItemChanged(null) which in turn tries to fire a focus event on the item's widget by finding the the accessible that is focused. This in turn creates a new DocAccessible with the dying PresShell that skips the PresShell shutdown method and thus creates the condition for a UAF.

Comment 10

[Eitan Isaacson [:eeejay]]

The ideal fix here is moving the setting of mIsDestroying in the PresShell above the DocAccessible shutdown routine. Since then we have checks in place that won't create a new AccDoc if IsDestroying is true.

The problem is that IsDestroying is also checked in 37 other places in layout code, and I don't want to risk changing the behavior of that flag. Maybe I'll push to try with auto and see what happens..

Comment 11

[Eitan Isaacson [:eeejay]]

Attachment: (secure)

Comment 12

[James Teh [:Jamie]]

(In reply to Eitan Isaacson [:eeejay] from comment #9)

When the DocAccessible is destroyed, following the destruction of the PresShell, we call FocusManager::ActiveItemChanged(null) which in turn tries to fire a focus event on the item's widget by finding the the accessible that is focused.

Nice find. While I agree we should totally protect against this in DocAccessible as you've done, I'd also argue that the DOM element really shouldn't still have focus while its PresShell is dying. But I guess that doesn't impact anything else...

Comment 13

[Eitan Isaacson [:eeejay]]

Comment on attachment 9527499 [details]
(secure)

Security Approval Request

• How easily could an exploit be constructed based on the patch?: Not easy
• 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?: beta
• If not all supported branches, which bug introduced the flaw?: bug 1997773
• Do you have backports for the affected branches?: Yes
• If not, how different, hard to create, and risky will they be?: not hard. i think the current patch should apply cleanly
• How likely is this patch to cause regressions; how much testing does it need?: i limited the regressions to the accessibility module. but i think the likelihood is small.
• Is the patch ready to land after security approval is given?: Yes
• Is Android affected?: Yes

Comment 14

[Tom Ritter [:tjr]]

Comment on attachment 9527499 [details]
(secure)

If relman wants to take this as a ridealong, it's approved to land and do so.

Comment 15

[Eitan Isaacson [:eeejay]]

I don't do this often enough. Do I now go and queue this patch in lando, or wait for relman?

Comment 16

[Ryan VanderMeulen [:RyanVM]]

Go ahead and land it. You can request Release approval on the patch when you're ready and we'll consider it for the 146 mid-cycle dot release in a couple weeks.

Comment 17

[BugBot [:suhaib / :marco]]

The bug is marked as tracked for firefox147 (nightly). We have limited time to fix this, the soft freeze is in 2 days. However, the bug still has low priority.

:fgriffith, could you please increase the priority for this tracked bug? If you disagree with the tracking decision, please talk with the release managers.

For more information, please visit BugBot documentation.

Comment 18

[Frank Griffith Jr]

Eitan is on it...no need for priority change

Comment 19

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/655ba8eacaaa
https://hg.mozilla.org/integration/autoland/rev/f13ef0643b12
Move Accessible doc shutdown to later in PresShell::Destroy. r=Jamie

Comment 20

[Ryan VanderMeulen [:RyanVM]]

https://hg-edge.mozilla.org/mozilla-central/rev/f13ef0643b12

Comment 21

[Dianna Smith [:diannaS]]

:eeejay did you want to request an uplift for release ? we build the dot release tomorrow

Comment 22

[Eitan Isaacson [:eeejay]]

Comment on attachment 9527499 [details]
(secure)

Beta/Release Uplift Approval Request

• User impact if declined/Reason for urgency: Possible UAF
• Is this code covered by automated tests?: No
• 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: Medium
• Why is the change risky/not risky? (and alternatives if risky): This is a change in shutdown order in presshell, so I am slightly nervous about it. The good news is that there seems to be no fallout in beta/nightly.
• String changes made/needed:
• Is Android affected?: Yes

Comment 23

[Dianna Smith [:diannaS]]

Comment on attachment 9527499 [details]
(secure)

Approved for 146.0.1 dot release

Comment 24

[Pulsebot]

https://github.com/mozilla-firefox/firefox/commit/17449244d3d5
https://hg.mozilla.org/releases/mozilla-release/rev/251cce9ffc1d

Comment 25

[Ciprian Georgiu, Desktop QA]

Hi, Irvan Kurniawan! Can you please verify if this issue is fixed on latest Nightly 147.0a1 and Release 146.0?

I cannot reproduce this myself using an affected Nightly asan build (2025-11-17) with Win 11 and Ubuntu 24.04.

Comment 26

[Irvan Kurniawan [:sourc7]]

(In reply to Ciprian Georgiu, Desktop QA from comment #25)

Hi, Irvan Kurniawan! Can you please verify if this issue is fixed on latest Nightly 147.0a1 and Release 146.0?

I cannot reproduce this myself using an affected Nightly asan build (2025-11-17) with Win 11 and Ubuntu 24.04.

Hi Ciprian, sure. I’m testing this right now.

Comment 27

[Irvan Kurniawan [:sourc7]]

Ok, I'm currently testing this on Arch Linux using testcase2.single-click.html.

Before testing, I ensured that Accessibility Activated status was set to true in about:support.

On m-c-20251117095036-asan-opt, and Firefox 146.0 (64-bit) I still able to reproduce the crash.

I confirmed on m-c-20251217162213-asan-opt, Firefox Nightly 148.0a1 (2025-12-17) (64-bit) I no longer able to reproduce the crash.

Comment 28

[Ciprian Georgiu, Desktop QA]

Thank you, Irvan!