Null-dereference READ · blink::Node* blink::NodeTraversal::TraverseNextTemplate
Reported by
cdsrc2...@gmail.com,
Sep 11
|
|||||||||
Issue description
UserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3396.99 Safari/537.36
Steps to reproduce the problem:
Steps to reproduce the problem:
1. download and unzip the release asan chromium :asan-linux-release-583299
2. Run ./chrome crash.html
What is the expected behavior?
What went wrong?
SVG <use> tag makes renderer to builds shadow and instance tree.But when associate related elements,the node traversal method Next() did not consider that if the current node is valid.
in src/third_party/blink/renderer/core/dom/node_traversal.h
template <class NodeType>
inline Node* NodeTraversal::TraverseNextTemplate(NodeType& current, const Node* stay_within) {
if (current.hasChildren()) <--- did not validate current.
return current.firstChild();
if (current == stay_within)
return nullptr;
if (current.nextSibling())
return current.nextSibling();
return NextAncestorSibling(current, stay_within);
}
The poc is simple:
<script>
customElements.define('edit-word',class {});
</script>
<code>edit-word</code>
<svg >
<g id="a"><edit-word/></g>
<use xlink:href="#a" />
</svg>
Did this work before? N/A
Chrome version: 71.0.3542.0 Channel: n/a
OS Version: 16.04
Flash Version:
,
Sep 11
Thanks for the report. Because this is a NULL dereference, there are no security implications, so I'll route it to the appropriate triage queue.
,
Sep 12
> SVG <use> tag makes renderer to builds shadow and instance tree.But when associate related elements,the node traversal method Next() did not consider that if the current node is valid.
> inline Node* NodeTraversal::TraverseNextTemplate(NodeType& current, const Node* stay_within) {
> if (current.hasChildren()) <--- did not validate current
|current| is a reference, so we don't need to validate |current| there.
It looks the caller side is wrong.
Maybe AssociateCorrespondingElements (or its callers) is doing a null-reference.
Maybe here? https://cs.chromium.org/chromium/src/third_party/blink/renderer/core/svg/svg_use_element.cc?rcl=32ede87df7295a8488e3a97f2f8a1ae55f69e49a&l=428
,
Sep 12
Automatically applying components based on crash stacktrace and information from OWNERS files. If this is incorrect, please apply the Test-Predator-Wrong-Components label.
,
Sep 12
Detailed report: https://clusterfuzz.com/testcase?key=5195257489391616 Job Type: linux_asan_chrome_mp Platform Id: linux Crash Type: Null-dereference READ Crash Address: 0x000000000010 Crash State: blink::Node* blink::NodeTraversal::TraverseNextTemplate<blink::ContainerNode con blink::Traversal<blink::SVGElement>::Next blink::SVGUseElement::CreateInstanceTree Sanitizer: address (ASAN) Regressed: https://clusterfuzz.com/revisions?job=linux_asan_chrome_mp&range=473072:473178 Reproducer Testcase: https://clusterfuzz.com/download?testcase_id=5195257489391616 See https://github.com/google/clusterfuzz-tools for more information.
,
Sep 12
,
Sep 12
,
Sep 12
I guess the first thing that goes wrong here is that the custom element definition is invoked at all (by the HTML parser) for the <edit-word/>.
,
Sep 13
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/96276821662e1bd554be4671936dd69c3de82e26 commit 96276821662e1bd554be4671936dd69c3de82e26 Author: Fredrik Söderquist <fs@opera.com> Date: Thu Sep 13 08:14:20 2018 Implement step 1 of "look up a custom element definition" Per [1], elements with a non-HTML namespace should cause a null custom element definition to be returned. Implement this step. [1] https://html.spec.whatwg.org/multipage/custom-elements.html#look-up-a-custom-element-definition Bug: 882773 Change-Id: Idc8f4c61b94af848e13acf4ff06da2c5f6842454 Reviewed-on: https://chromium-review.googlesource.com/1221325 Reviewed-by: Kent Tamura <tkent@chromium.org> Commit-Queue: Fredrik Söderquist <fs@opera.com> Cr-Commit-Position: refs/heads/master@{#590949} [add] https://crrev.com/96276821662e1bd554be4671936dd69c3de82e26/third_party/WebKit/LayoutTests/external/wpt/custom-elements/parser/parser-custom-element-in-foreign-content.html [modify] https://crrev.com/96276821662e1bd554be4671936dd69c3de82e26/third_party/blink/renderer/core/html/parser/html_construction_site.cc [modify] https://crrev.com/96276821662e1bd554be4671936dd69c3de82e26/third_party/blink/renderer/core/html/parser/html_construction_site.h
,
Sep 13
,
Sep 14
ClusterFuzz has detected this issue as fixed in range 590948:590950. Detailed report: https://clusterfuzz.com/testcase?key=5195257489391616 Job Type: linux_asan_chrome_mp Platform Id: linux Crash Type: Null-dereference READ Crash Address: 0x000000000010 Crash State: blink::Node* blink::NodeTraversal::TraverseNextTemplate<blink::ContainerNode con blink::Traversal<blink::SVGElement>::Next blink::SVGUseElement::CreateInstanceTree Sanitizer: address (ASAN) Regressed: https://clusterfuzz.com/revisions?job=linux_asan_chrome_mp&range=473072:473178 Fixed: https://clusterfuzz.com/revisions?job=linux_asan_chrome_mp&range=590948:590950 Reproducer Testcase: https://clusterfuzz.com/download?testcase_id=5195257489391616 See https://github.com/google/clusterfuzz-tools for more information. If you suspect that the result above is incorrect, try re-doing that job on the test case report page.
,
Sep 14
ClusterFuzz testcase 5195257489391616 is verified as fixed, so closing issue as verified. If this is incorrect, please add ClusterFuzz-Wrong label and re-open the issue. |
|||||||||
►
Sign in to add a comment |
|||||||||
Comment 1 by ClusterFuzz
, Sep 11