Closed Bug 1954247 Opened 1 year ago Closed 11 months ago

Assertion failure: slowNode == node (These should always be in sync!), at /builds/worker/checkouts/gecko/dom/base/nsINode.cpp:576

Categories

(Core :: SVG, defect)

defect

Tracking

()

VERIFIED FIXED
Tracking Status
firefox-esr115 --- unaffected
firefox-esr128 --- unaffected
firefox136 --- unaffected
firefox137 --- disabled
firefox138 --- disabled
firefox139 --- fixed
firefox140 --- fixed

People

(Reporter: tsmith, Assigned: longsonr)

References

(Blocks 1 open bug, Regression)

Details

(4 keywords, Whiteboard: [bugmon:bisected,confirmed])

Attachments

(2 files)

Attached file testcase.html

Found while fuzzing m-c 20250312-bec9c7796872 (--enable-debug --enable-fuzzing)

To reproduce via Grizzly Replay:

$ pip install fuzzfetch grizzly-framework --upgrade
$ python -m fuzzfetch -d --fuzzing -n firefox
$ python -m grizzly.replay.bugzilla ./firefox/firefox <bugid>

Assertion failure: slowNode == node (These should always be in sync!), at /builds/worker/checkouts/gecko/dom/base/nsINode.cpp:576

#0 0x7680b87ce416 in MOZ_CrashSequence /builds/worker/workspace/obj-build/dist/include/mozilla/Assertions.h:267:3
#1 0x7680b87ce416 in nsINode::SubtreeRoot() const /builds/worker/checkouts/gecko/dom/base/nsINode.cpp:576:5
#2 0x7680ba1ccca5 in mozilla::ShouldClearTargets(mozilla::WidgetEvent*) /builds/worker/checkouts/gecko/dom/events/EventDispatcher.cpp:759:22
#3 0x7680ba1cb5fa in mozilla::EventDispatcher::Dispatch(mozilla::dom::EventTarget*, nsPresContext*, mozilla::WidgetEvent*, mozilla::dom::Event*, nsEventStatus*, mozilla::EventDispatchingCallback*, nsTArray<mozilla::dom::EventTarget*>*) /builds/worker/checkouts/gecko/dom/events/EventDispatcher.cpp:1130:24
#4 0x7680ba1ce4ea in mozilla::EventDispatcher::DispatchDOMEvent(mozilla::dom::EventTarget*, mozilla::WidgetEvent*, mozilla::dom::Event*, nsPresContext*, nsEventStatus*) /builds/worker/checkouts/gecko/dom/events/EventDispatcher.cpp
#5 0x7680b883ae96 in nsINode::DispatchEvent(mozilla::dom::Event&, mozilla::dom::CallerType, mozilla::ErrorResult&) /builds/worker/checkouts/gecko/dom/base/nsINode.cpp:1495:17
#6 0x7680ba1dc637 in mozilla::dom::EventTarget::DispatchEvent(mozilla::dom::Event&, mozilla::ErrorResult&) /builds/worker/checkouts/gecko/dom/events/EventTarget.cpp:214:13
#7 0x7680ba184eed in mozilla::AsyncEventDispatcher::DispatchEventOnTarget(mozilla::dom::EventTarget*, nsTSubstring<char16_t> const&, mozilla::CanBubble, mozilla::ChromeOnlyDispatch, mozilla::Composed) /builds/worker/checkouts/gecko/dom/events/AsyncEventDispatcher.cpp:75:3
#8 0x7680ba184b89 in mozilla::AsyncEventDispatcher::Run() /builds/worker/checkouts/gecko/dom/events/AsyncEventDispatcher.cpp:62:5
#9 0x7680b672bef7 in mozilla::RunnableTask::Run() /builds/worker/checkouts/gecko/xpcom/threads/TaskController.cpp:703:16
#10 0x7680b67253ce in mozilla::TaskController::DoExecuteNextTaskOnlyMainThreadInternal(mozilla::detail::BaseAutoLock<mozilla::Mutex&> const&) /builds/worker/checkouts/gecko/xpcom/threads/TaskController.cpp:1252:20
#11 0x7680b6724107 in mozilla::TaskController::ExecuteNextTaskOnlyMainThreadInternal(mozilla::detail::BaseAutoLock<mozilla::Mutex&> const&) /builds/worker/checkouts/gecko/xpcom/threads/TaskController.cpp:1075:15
#12 0x7680b6724585 in mozilla::TaskController::ProcessPendingMTTask(bool) /builds/worker/checkouts/gecko/xpcom/threads/TaskController.cpp:639:36
#13 0x7680b6732fc6 in operator() /builds/worker/checkouts/gecko/xpcom/threads/TaskController.cpp:333:37
#14 0x7680b6732fc6 in mozilla::detail::RunnableFunction<mozilla::TaskController::TaskController()::$_0>::Run() /builds/worker/checkouts/gecko/xpcom/threads/nsThreadUtils.h:548:5
#15 0x7680b6745023 in nsThread::ProcessNextEvent(bool, bool*) /builds/worker/checkouts/gecko/xpcom/threads/nsThread.cpp:1159:16
#16 0x7680b674b64f in NS_ProcessNextEvent(nsIThread*, bool) /builds/worker/checkouts/gecko/xpcom/threads/nsThreadUtils.cpp:480:10
#17 0x7680b72aaa07 in mozilla::ipc::MessagePump::Run(base::MessagePump::Delegate*) /builds/worker/checkouts/gecko/ipc/glue/MessagePump.cpp:85:21
#18 0x7680b7205411 in RunHandler /builds/worker/checkouts/gecko/ipc/chromium/src/base/message_loop.cc:362:3
#19 0x7680b7205411 in MessageLoop::Run() /builds/worker/checkouts/gecko/ipc/chromium/src/base/message_loop.cc:344:3
#20 0x7680bbf4cb08 in nsBaseAppShell::Run() /builds/worker/checkouts/gecko/widget/nsBaseAppShell.cpp:148:27
#21 0x7680bc00f794 in nsAppShell::Run() /builds/worker/checkouts/gecko/widget/gtk/nsAppShell.cpp:539:33
#22 0x7680bcf2188b in XRE_RunAppShell() /builds/worker/checkouts/gecko/toolkit/xre/nsEmbedFunctions.cpp:646:20
#23 0x7680b72ab8b4 in mozilla::ipc::MessagePumpForChildProcess::Run(base::MessagePump::Delegate*) /builds/worker/checkouts/gecko/ipc/glue/MessagePump.cpp:235:9
#24 0x7680b7205411 in RunHandler /builds/worker/checkouts/gecko/ipc/chromium/src/base/message_loop.cc:362:3
#25 0x7680b7205411 in MessageLoop::Run() /builds/worker/checkouts/gecko/ipc/chromium/src/base/message_loop.cc:344:3
#26 0x7680bcf20cc9 in XRE_InitChildProcess(int, char**, XREChildData const*) /builds/worker/checkouts/gecko/toolkit/xre/nsEmbedFunctions.cpp:584:34
#27 0x57d5a1cad0ae in main /builds/worker/checkouts/gecko/browser/app/nsBrowserApp.cpp:397:22

Verified bug as reproducible on mozilla-central 20250316213034-571bfad95411.
The bug appears to have been introduced in the following build range:

Start: 7a2ecdf66a2b4da89382a70fcdec900c9996f88a (20250311080719)
End: 68b574aa3995b60920c80ed4cff03e68898d5ebc (20250311113914)
Pushlog: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=7a2ecdf66a2b4da89382a70fcdec900c9996f88a&tochange=68b574aa3995b60920c80ed4cff03e68898d5ebc

Keywords: regression
Whiteboard: [bugmon:bisected,confirmed]

Tom, could this have been caused by bug 1951893 based on the above regression range?

Flags: needinfo?(tschuster)

This uses the <discard> element, so very likely bug 1951895.

Flags: needinfo?(tschuster)
Flags: needinfo?(longsonr)

This may be triggered by discard but the problem is elsewhere. I'm not familiar with the crashing code.

Flags: needinfo?(longsonr)

The issue is that <discard> ends up removing DOM nodes during BindToTree, which leaves the DOM in a wrong state:

#0  nsContentUtils::MaybeFireNodeRemoved (aChild=0x729a1aa0a080, aParent=0x729a1aa035e0)
    at /home/emilio/src/moz/gecko-2/dom/base/nsContentUtils.cpp:5573
#1  0x0000729a256a122e in nsINode::RemoveChild (this=this@entry=0x729a1aa035e0, aOldChild=..., aError=...)
    at /home/emilio/src/moz/gecko-2/dom/base/nsINode.cpp:958
#2  0x0000729a256a5fe7 in nsINode::Remove (this=0x729a1aa0a080) at /home/emilio/src/moz/gecko-2/dom/base/nsINode.cpp:2172
#3  0x0000729a28ddcd27 in mozilla::ProcessDiscards (aDiscards=...)
    at /home/emilio/src/moz/gecko-2/dom/smil/SMILAnimationController.cpp:257
#4  0x0000729a28ddc507 in mozilla::SMILAnimationController::DoMilestoneSamples (this=this@entry=0x729a1bceb580)
    at /home/emilio/src/moz/gecko-2/dom/smil/SMILAnimationController.cpp:510
#5  0x0000729a28dda9e6 in mozilla::SMILAnimationController::DoSample (this=0x729a1bceb580, aSkipUnchangedContainers=true)
    at /home/emilio/src/moz/gecko-2/dom/smil/SMILAnimationController.cpp:286
#6  0x0000729a28dea32f in mozilla::SMILTimeContainer::Sample (this=0x729a1bceb580)
    at /home/emilio/src/moz/gecko-2/dom/smil/SMILTimeContainer.cpp:161
#7  0x0000729a28ddd9fa in mozilla::SMILAnimationController::AddChild (this=0x729a1bceb580, aChild=<optimized out>)
    at /home/emilio/src/moz/gecko-2/dom/smil/SMILAnimationController.cpp:667
#8  0x0000729a28829384 in mozilla::dom::SVGSVGElement::BindToTree (this=0x729a1aa0a080, aContext=<optimized out>, aParent=...)
    at /home/emilio/src/moz/gecko-2/dom/svg/SVGSVGElement.cpp:338
#9  0x0000729a25505683 in mozilla::dom::Element::BindToTree (this=0x729a1aa035e0, aContext=..., aParent=...)
    at /home/emilio/src/moz/gecko-2/dom/base/Element.cpp:2225
#10 0x0000729a2545f343 in nsStyledElement::BindToTree (this=0x729a1aa0a080, aContext=..., aParent=...)
    at /home/emilio/src/moz/gecko-2/dom/base/nsStyledElement.cpp:197
#11 0x0000729a27644a67 in nsGenericHTMLElement::BindToTree (this=0x729a1aa0a080, aContext=..., aParent=...)
    at /home/emilio/src/moz/gecko-2/dom/html/nsGenericHTMLElement.cpp:499
#12 0x0000729a256a3d40 in nsINode::InsertChildBefore
    (this=0x729a1aa03160, aKid=0x729a1aa035e0, aBeforeThis=0x0, aNotify=true, aRv=...)
    at /home/emilio/src/moz/gecko-2/dom/base/nsINode.cpp:1697
#13 0x0000729a256a9097 in nsINode::ReplaceOrInsertBefore
    (this=0x729a1aa03160, aReplace=false, aNewChild=0x729a1aa035e0, aRefChild=<optimized out>, aError=...)
    at /home/emilio/src/moz/gecko-2/dom/base/nsINode.cpp:2982
#14 0x0000729a25bfb644 in nsINode::InsertBefore (this=0x729a1aa03160, aNode=..., aChild=0x0, aError=...)
    at /home/emilio/src/moz/gecko-2/dom/base/nsINode.h:2316
#15 nsINode::AppendChild (this=0x729a1aa03160, aNode=..., aError=...) at /home/emilio/src/moz/gecko-2/dom/base/nsINode.h:2323
#16 mozilla::dom::Node_Binding::appendChild

The wrong DOM state can probably be abused.

Group: dom-core-security
Flags: needinfo?(longsonr)
Attached patch patchSplinter Review

straw man patch.

Flags: needinfo?(longsonr)

Given the regressor and the proposed patch, I'll move this to SVG.

The wrong DOM state can probably be abused.

How bad do you think the danger is? Are we talking about a use-after-free or some vague check confusion that might be a problem? I'm trying to decide whether this is more of a sec-moderate or a sec-high. Thanks.

Group: dom-core-security → layout-core-security
Component: DOM: Core & HTML → SVG
Flags: needinfo?(emilio)

Have raised bug 1954608 to disable discard in beta.

See Also: → 1954608

(In reply to Andrew McCreight [:mccr8] from comment #7)

How bad do you think the danger is? Are we talking about a use-after-free or some vague check confusion that might be a problem? I'm trying to decide whether this is more of a sec-moderate or a sec-high. Thanks.

It's hard to say, I wouldn't be too surprised if it could end up in a UAF, things like the cycle collector make assumptions about the dom shape...

Flags: needinfo?(emilio)

The bug is marked as tracked for firefox137 (beta). We have limited time to fix this, the soft freeze is in 9 days. However, the bug still isn't assigned.

:fgriffith, could you please find an assignee for this tracked bug? Given that it is a regression and we know the cause, we could also simply backout the regressor. If you disagree with the tracking decision, please talk with the release managers.

For more information, please visit BugBot documentation.

Flags: needinfo?(fgriffith)

bug 1954608 has fixed this for firefox137 (beta) by disabling the regressor.

Thanks. I'll be conservative and mark it sec-high.

Keywords: sec-high
See Also: → 1953648

Tentatively assigning to longsonr since I think he's looking at this; though if we disable discard on all branches, there's maybe less of a rush to fix it.

Assignee: nobody → longsonr
Flags: needinfo?(fgriffith)

(In reply to Robert Longson [:longsonr] from comment #11)

bug 1954608 has fixed this for firefox137 (beta) by disabling the regressor.

We've disabled discard on mozilla-central for Nightly 138 as well now, so users aren't affected by this on any branch at this point (unless they toggle the pref / until we reenable it via the now-reopened bug 1945330).

Triaging as S3 given that this is now off-by-default on all channels.

Per discussion in #security on slack, we should still keep this flagged as sec-high, but of course it's now lower-priority than other sec-high bugs given that it requires a manual about:config tweak in order to trigger.

Blocks: 1945330
Severity: -- → S3

The severity field for this bug is set to S3. However, the bug is flagged with the sec-high keyword.
:longsonr, could you consider increasing the severity of this security bug?

For more information, please visit BugBot documentation.

Flags: needinfo?(longsonr)

No, it's preffed off in all branches.

Flags: needinfo?(longsonr)

We can unset the tracking flag for 137, too; no need to track this now that the required feature is disabled.

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

Fixed by bug 1958839

Status: NEW → RESOLVED
Closed: 11 months ago
Resolution: --- → FIXED

Yup - we can consider it it fixed-by-backout (rather than just disabled-by-pref) for 139 and 140, too.

(Not sure if 'unaffected' or 'fixed' is the more appropriate release-branch-status to reflect that, but it probably doesn't matter much.)

Group: layout-core-security → core-security-release
QA Whiteboard: [sec] [qa-triage-done-c140/b139]
Flags: qe-verify-
Group: core-security-release

Verified bug as fixed on rev mozilla-central 20251219050723-739c12f204f1.
Removing bugmon keyword as no further action possible. Please review the bug and re-add the keyword for further analysis.

Status: RESOLVED → VERIFIED
Keywords: bugmon
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: