Find it and CL did not provide any possible suspects.
Using Code Search for the file, "MultiColumnFragmentainerGroup.cpp" assigning to the concern owner.

Suspecting Commit#
https://chromium.googlesource.com/chromium/src/+/90a520011b9e1f70355987371360540c922f4fc9

@mstensho -- Could you please look into the issue, kindly re-assign if this is not related to your changes.
Thank You.

The root cause here is that we get a negative content box width, and then resolve vertical percentage padding against it. No multicol required:

    <div id="#outer" style="overflow:scroll; width:1px;">
        <div id="inner" style="float:right; width:20px; height:100px;"></div>
    </div>

The specified content-box width of #outer is 1px. The scrollbar eats all space for #outer, so it should end up with a content box width of 0. Instead it gets a content box width of -14px (exact number depends on the theme's scrollbar size), because it has set its border box width to 1px, and then subtracts the width of the scrollbar.

The left position of #inner should here -20px relatively to its containing block, since the width of its containing block (#outer) should be 0. Instead it's -34px here, since the width of the containing block ends up as -14px.

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

commit 47305a33360149240ab99c57c6c65ff5f05fa68e
Author: mstensho <mstensho@opera.com>
Date: Thu Feb 23 19:19:14 2017

Avoid negative content box sizes.

Negative values had two possible causes:

1. Subtracting the scrollbar size from the border box size. Scrollbars do not
affect the border box size, but they occupy space between some border edge and
padding edge. This means that the presence of a scrollbar on an object reduces
the size of the content box and the containing block established by said
object. This means that if e.g. the specified width of an object is 10px and it
has a vertical scrollbar that takes up more than that, e.g. 15px, the content
box width should become 0, not -5px.

2. Subtracting two huge (or even saturated) LayoutUnit values from one
LayoutUnit value. When we during layout convert a specified content-box width
to border-box (via padding-box), which is what LayoutBox::m_frameRect uses, we
may end up with saturated LayoutUnit values, so that:
LayoutUnit specified_content_box_width = <whatever, something nice, maybe>;
LayoutUnit left_padding = LayoutUnit::max() /*(or something huge, at least)*/;
LayoutUnit right_padding = LayoutUnit::max() /*(or something huge, at least);*/
LayoutUnit padding_box_width = content_box_width + left_padding + right_padding;
LayoutUnit content_box_width = padding_box_width - left_padding - right_padding;
Here, content_box_width won't be the same as specified_content_box_width,
because padding_box_width got saturated. That's kind of inevitable, with
saturated arithmetic and all, but what's worse is that we used to end up with a
negative value in content_box_width, which is illegal. So just clamp negative
values to 0 to avoid that.

Negative box sizes have various kinds of ill effects, such as inline-axis
misalignment and unwanted negative block direction progression. It was possible
to get negative padding (which is illegal) resolved from percentage values.
This in turn caused unnecessary assertion failures in multicol.

Attempted to come up with sensible layout tests that don't make assumptions
about how the engine deals with extreme values internally.

BUG= 683554 , 683090 

Review-Url: https://codereview.chromium.org/2716583002
Cr-Commit-Position: refs/heads/master@{#452578}

[add] https://crrev.com/47305a33360149240ab99c57c6c65ff5f05fa68e/third_party/WebKit/LayoutTests/fast/block/large-border-abspos.html
[add] https://crrev.com/47305a33360149240ab99c57c6c65ff5f05fa68e/third_party/WebKit/LayoutTests/fast/block/large-padding-vertical-writing-mode.html
[add] https://crrev.com/47305a33360149240ab99c57c6c65ff5f05fa68e/third_party/WebKit/LayoutTests/fast/block/large-padding.html
[add] https://crrev.com/47305a33360149240ab99c57c6c65ff5f05fa68e/third_party/WebKit/LayoutTests/fast/block/scrollbar-wider-than-border-box.html
[add] https://crrev.com/47305a33360149240ab99c57c6c65ff5f05fa68e/third_party/WebKit/LayoutTests/fast/multicol/large-padding-crash.html
[add] https://crrev.com/47305a33360149240ab99c57c6c65ff5f05fa68e/third_party/WebKit/LayoutTests/fast/multicol/scrollbar-wider-than-content-box-crash.html
[modify] https://crrev.com/47305a33360149240ab99c57c6c65ff5f05fa68e/third_party/WebKit/Source/core/layout/LayoutBox.cpp
[modify] https://crrev.com/47305a33360149240ab99c57c6c65ff5f05fa68e/third_party/WebKit/Source/core/layout/LayoutBox.h

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

commit 0b389da84405eef38ee9f9e54f51352a6c1508f3
Author: mstensho <mstensho@opera.com>
Date: Mon Feb 27 13:47:02 2017

Allow flow thread portion logical bottom to be above its logical top.

We used to try to prevent this, as an attempt to make sure that no
fragmentainer group would have overlapping flow thread portion rectangles with
other fragmentainer groups. But that was already easily achievable with e.g. an
empty block between two column spanners anyway.

There is a legitimate reason for the flow thread portion bottom to be above the
top: negative margins.

Introduce MultiColumnFragmentainerGroup::logicalHeightInFlowThreadAt().
Less duplicated code. Some extra care is now needed, to make sure that we don't
end up with negative logical heights.

BUG= 688760 , 683090 , 683554 

Review-Url: https://codereview.chromium.org/2709013007
Cr-Commit-Position: refs/heads/master@{#453201}

[add] https://crrev.com/0b389da84405eef38ee9f9e54f51352a6c1508f3/third_party/WebKit/LayoutTests/fast/multicol/span/spanner-after-negative-margin-bottom-crash-2.html
[add] https://crrev.com/0b389da84405eef38ee9f9e54f51352a6c1508f3/third_party/WebKit/LayoutTests/fast/multicol/span/spanner-after-negative-margin-bottom-crash.html
[modify] https://crrev.com/0b389da84405eef38ee9f9e54f51352a6c1508f3/third_party/WebKit/Source/core/layout/LayoutMultiColumnFlowThread.cpp
[modify] https://crrev.com/0b389da84405eef38ee9f9e54f51352a6c1508f3/third_party/WebKit/Source/core/layout/LayoutMultiColumnSet.h
[modify] https://crrev.com/0b389da84405eef38ee9f9e54f51352a6c1508f3/third_party/WebKit/Source/core/layout/MultiColumnFragmentainerGroup.cpp
[modify] https://crrev.com/0b389da84405eef38ee9f9e54f51352a6c1508f3/third_party/WebKit/Source/core/layout/MultiColumnFragmentainerGroup.h

ClusterFuzz has detected this issue as fixed in range 452556:452596.

Detailed report: https://cluster-fuzz.appspot.com/testcase?key=4566405140971520

Fuzzer: inferno_layout_test_unmodified
Job Type: linux_debug_content_shell_drt
Platform Id: linux

Crash Type: CHECK failure
Crash Address: 
Crash State:
  logicalTopInFlowThread <= logicalBottomInFlowThread in MultiColumnFragmentainerG
  blink::MultiColumnFragmentainerGroup::columnIntervalForBlockRangeInFlowThread
  blink::MultiColumnFragmentainerGroup::fragmentsBoundingBox
  
Sanitizer: address (ASAN)

Regressed: https://cluster-fuzz.appspot.com/revisions?job=linux_debug_content_shell_drt&range=342718:342773
Fixed: https://cluster-fuzz.appspot.com/revisions?job=linux_debug_content_shell_drt&range=452556:452596

Reproducer Testcase: https://cluster-fuzz.appspot.com/download/AMIfv97dI6lLLJZCAt8WAn1U5PqHfZ5W3STEKNfhJ0WwG6OvnprN_whGV4ov6a-kfFvURhIT4BH1Gtx5dlowQHp0QHC-UGUIXmuMHtYRTV36XrcJJeyDWYdS7qoavP2Okec6FRuIQHyoqlrVeMTKeJZJFwjmauZLqDrSd2XO6_GXnA8t0HyYIpgQGCtphJqzgapiAf7BKIElniDo0eMXpaT1WY5yjX3VAb1z2pCwFGE0s3ckVn_Yv2bTpeJzQm500LcaeHFII1BVu4CHB7WRyoPAdQrHk-ERsaho-c1JDG0ah-lDZCahYMqU9nGh8s3hdh4Db9hQgxHaY935aKxWBpw2F3CU22Mh7B5J6QOTzX3q1xXBHrxUOLM?testcase_id=4566405140971520


See https://dev.chromium.org/Home/chromium-security/bugs/reproducing-clusterfuzz-bugs for more information.

If you suspect that the result above is incorrect, try re-doing that job on the test case report page.

ClusterFuzz has detected this issue as fixed in range 452556:452596.

Detailed report: https://cluster-fuzz.appspot.com/testcase?key=4566405140971520

Fuzzer: inferno_layout_test_unmodified
Job Type: linux_debug_content_shell_drt
Platform Id: linux

Crash Type: CHECK failure
Crash Address: 
Crash State:
  logicalTopInFlowThread <= logicalBottomInFlowThread in MultiColumnFragmentainerG
  blink::MultiColumnFragmentainerGroup::columnIntervalForBlockRangeInFlowThread
  blink::MultiColumnFragmentainerGroup::fragmentsBoundingBox
  
Sanitizer: address (ASAN)

Regressed: https://cluster-fuzz.appspot.com/revisions?job=linux_debug_content_shell_drt&range=342718:342773
Fixed: https://cluster-fuzz.appspot.com/revisions?job=linux_debug_content_shell_drt&range=452556:452596

Reproducer Testcase: https://cluster-fuzz.appspot.com/download/AMIfv97dI6lLLJZCAt8WAn1U5PqHfZ5W3STEKNfhJ0WwG6OvnprN_whGV4ov6a-kfFvURhIT4BH1Gtx5dlowQHp0QHC-UGUIXmuMHtYRTV36XrcJJeyDWYdS7qoavP2Okec6FRuIQHyoqlrVeMTKeJZJFwjmauZLqDrSd2XO6_GXnA8t0HyYIpgQGCtphJqzgapiAf7BKIElniDo0eMXpaT1WY5yjX3VAb1z2pCwFGE0s3ckVn_Yv2bTpeJzQm500LcaeHFII1BVu4CHB7WRyoPAdQrHk-ERsaho-c1JDG0ah-lDZCahYMqU9nGh8s3hdh4Db9hQgxHaY935aKxWBpw2F3CU22Mh7B5J6QOTzX3q1xXBHrxUOLM?testcase_id=4566405140971520


See https://dev.chromium.org/Home/chromium-security/bugs/reproducing-clusterfuzz-bugs for more information.

If you suspect that the result above is incorrect, try re-doing that job on the test case report page.