Predator and CL could not provide any possible suspects.
Using the code search for the file, “grid_baseline_alignment.cc” assigning to concern owner from GIT blame.

Suspecting Commit#
https://chromium.googlesource.com/chromium/src/+/a60e495ea2084539e350f51125843dc207868d58
@jfernandez -- Could you please look into this issue, kindly reassign if it has nothing to do with your changes.

Also, CC'ing the reviewer of the suspect file - svillar@

Thank You.

I reproduced the issue and created a simplified test case, which I attach now.

Automatically applying components based on crash stacktrace and information from OWNERS files.

If this is incorrect, please apply the Test-Predator-Wrong-Components label.

Attached an even more simplified test case to reproduce the issue.

Deleted: crash-baseline-algorithm-1.html 118 bytes

crash-baseline-algorithm-1.html 118 bytes View Download

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

commit 07d4cc08bc84677108d949e0b356f19e6c81cbc0
Author: Javier Fernandez <jfernandez@igalia.com>
Date: Thu Jun 14 22:46:15 2018

[css-grid] Layout items to figure out the need of synthesized baseline

We have landed several patches with refactoring and new logic in order
to integrate the baseline alignment into the track sizing algorithm. We
need to run this new logic both during layout and intrinsic size.

Additionally, the CSS WG resolved that when the baseline alignment cause
a cyclic sizing dependency, such items should not participate in such
baseline alignment.

One of the pre-conditions for the above mentioned cyclic dependency is
the need of a synthesized baseline. There are several scenarios that
may lead to this pre-condition, but most of them can be detected by
calling FirstLineBoxBaseline() on the item under evaluation; if we get
-1 as result it means that the item has no baseline and it needs to
synthesize it.

However, the FirstLineBoxBaseline always returns -1 if the item was not
laid out yet. The bug we are trying resolve has its root cause in this
scenario. We are working assuming that an item doesn't participate,
while we request for its Baseline Context during layout, since the
result of the FirstLineBaseline call is different during this phase.

This CL ensures the item is laid our before it's evaluated to
participate in the baseline alignment.

Bug:  850510 
Change-Id: I94823f08c8268e36926b074e9f84e67fb9c49baa
Reviewed-on: https://chromium-review.googlesource.com/1096041
Commit-Queue: Javier Fernandez <jfernandez@igalia.com>
Reviewed-by: Manuel Rego Casasnovas <rego@igalia.com>
Cr-Commit-Position: refs/heads/master@{#567451}
[add] https://crrev.com/07d4cc08bc84677108d949e0b356f19e6c81cbc0/third_party/WebKit/LayoutTests/fast/css-grid-layout/grid-self-baseline-and-relative-sized-items-crash-expected.txt
[add] https://crrev.com/07d4cc08bc84677108d949e0b356f19e6c81cbc0/third_party/WebKit/LayoutTests/fast/css-grid-layout/grid-self-baseline-and-relative-sized-items-crash.html
[modify] https://crrev.com/07d4cc08bc84677108d949e0b356f19e6c81cbc0/third_party/blink/renderer/core/layout/grid_track_sizing_algorithm.cc
[modify] https://crrev.com/07d4cc08bc84677108d949e0b356f19e6c81cbc0/third_party/blink/renderer/core/layout/layout_grid.cc
[modify] https://crrev.com/07d4cc08bc84677108d949e0b356f19e6c81cbc0/third_party/blink/renderer/core/layout/layout_grid.h

THis issue should be FIXED now.

ClusterFuzz has detected this issue as fixed in range 567450:567451.

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

Fuzzer: ifratric-browserfuzzer-v3
Job Type: linux_ubsan_chrome
Platform Id: linux

Crash Type: Null-dereference READ
Crash Address: 0x000000000000
Crash State:
  begin
  blink::BaselineContext::FindCompatibleSharedGroup
  GetSharedGroup
  
Sanitizer: undefined (UBSAN)

Regressed: https://clusterfuzz.com/revisions?job=linux_ubsan_chrome&range=562683:563900
Fixed: https://clusterfuzz.com/revisions?job=linux_ubsan_chrome&range=567450:567451

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

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 4697612331253760 is verified as fixed, so closing issue as verified.

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