https://chromium-review.googlesource.com/616374 is the most likely culprit in regression range.

Other candidates include:
https://chromium-review.googlesource.com/615846
https://chromium-review.googlesource.com/612754

Could you take look?
It seems <select id="htmlvar00011"><optgroup id="htmlvar00013"></select>
causes nullptr in EphemeralRangeInFlatTree::Nodes().

Issue 756467 has been merged into this issue.

Issue 757362 has been merged into this issue.

 Issue 758145  has been merged into this issue.

ClusterFuzz has detected this issue as fixed in range 496835:496881.

Detailed report: https://clusterfuzz.com/testcase?key=4529134880686080

Fuzzer: ifratric-browserfuzzer-v3
Job Type: mac_asan_chrome
Platform Id: mac

Crash Type: Null-dereference READ
Crash Address: 0x000000000010
Crash State:
  blink::LayoutSelection::Commit
  blink::LayoutView::CommitPendingSelection
  blink::PaintLayerCompositor::UpdateIfNeededRecursiveInternal
  
Sanitizer: address (ASAN)

Regressed: https://clusterfuzz.com/revisions?job=mac_asan_chrome&range=494993:495051
Fixed: https://clusterfuzz.com/revisions?job=mac_asan_chrome&range=496835:496881

Reproducer Testcase: https://clusterfuzz.com/download?testcase_id=4529134880686080

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.

ClusterFuzz testcase 4529134880686080 is verified as fixed, so closing issue as verified.

If this is incorrect, please add ClusterFuzz-Wrong label and re-open the issue.

We haven't landed the fix yet :)

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/9323a73cb8d48e164e284871aee7686baaba2825

commit 9323a73cb8d48e164e284871aee7686baaba2825
Author: Kent Tamura <tkent@chromium.org>
Date: Fri Aug 25 05:52:32 2017

Do not trigger layout inside HTMLFormControlElement::SetNeedsValidityCheck().

SetNeedsValidityCheck() can be called in the middle of a DOM mutation,
and the default ValidationMessageClient::ShowValidationMessage() called
in HTMLFormControlElement::UpdateVisibleValidationMessage() triggers
force layout. We avoid it by calling UpdateVisibleValidationMessage()
later.

Bug:  756408 
Change-Id: Ic658652bc851e27d5eeb9496e211100fa091e372
Reviewed-on: https://chromium-review.googlesource.com/630418
Commit-Queue: Yoichi Osato <yoichio@chromium.org>
Reviewed-by: Yoichi Osato <yoichio@chromium.org>
Cr-Commit-Position: refs/heads/master@{#497332}
[modify] https://crrev.com/9323a73cb8d48e164e284871aee7686baaba2825/third_party/WebKit/Source/core/html/HTMLFormControlElement.cpp
[modify] https://crrev.com/9323a73cb8d48e164e284871aee7686baaba2825/third_party/WebKit/Source/core/html/HTMLFormControlElementTest.cpp