Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: ba3be26a064abdfdcc87698f202ff0be33452663
https://github.com/WebKit/WebKit/commit/ba3be26a064abdfdcc87698f202ff0be33452663
Author: Antti Koivisto <[email protected]>
Date: 2026-06-30 (Tue, 30 Jun 2026)
Changed paths:
A
LayoutTests/fast/custom-elements/xml-parser-reparent-during-construction-crash-expected.txt
A
LayoutTests/fast/custom-elements/xml-parser-reparent-during-construction-crash.xhtml
M Source/WebCore/xml/parser/XMLDocumentParserLibxml2.cpp
Log Message:
-----------
[WebCore] use-after-free in Style::TreeResolver —
XMLDocumentParser::startElementNs missing parentNode re-check after
custom-element upgrade
rdar://177479772
Reviewed by Ryosuke Niwa.
Draining the custom element reaction stack in startElementNs runs the
constructor synchronously, which can re-parent newElement, adopt it into
another document, or detach the current parser node. parserAppendChild
requires its argument to have no parent and to share our document, so
falling through into it leaves the tree linked into two child lists.
Re-check those invariants after the reaction stack drains and stop
parsing if any of them no longer holds. A spec-aligned follow-up should
route XML element creation through constructElementWithFallback like
HTMLDocumentParser does, which post-validates and falls back to
HTMLUnknownElement; a FIXME records that.
Test: fast/custom-elements/xml-parser-reparent-during-construction-crash.xhtml
*
LayoutTests/fast/custom-elements/xml-parser-reparent-during-construction-crash-expected.txt:
Added.
*
LayoutTests/fast/custom-elements/xml-parser-reparent-during-construction-crash.xhtml:
Added.
* Source/WebCore/xml/parser/XMLDocumentParserLibxml2.cpp:
(WebCore::XMLDocumentParser::startElementNs):
Originally-landed-as: 305413.947@safari-7624-branch (19beaaec03d0).
rdar://180436996
Canonical link: https://commits.webkit.org/316181@main
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications