The result is a list of CLs that change the crashed files. 

Author: lukasza
Project: chromium
Changelist: https://chromium.googlesource.com/chromium/src/+/3d4638361677cd371c0cea2030499a00c5e8ad13
Time: Fri Dec 02 16:53:36 2016
Lines 3017 of file CompositedLayerMapping.cpp which potentially caused crash are changed in this cl (frame #4, "blink::CompositedLayerMapping::computeInterestRect").
Minimum distance from crash line to modified line: 0. (file: CompositedLayerMapping.cpp, crashed on: 3017, modified: 3017).

schenney@, could you PTAL?

My change (mentioned in #c1 above) only renamed some identifiers and shouldn't have caused any behavior changes.  Maybe somebody from third_party/WebKit/Source/core/paint/OWNERS can take a look - I guess one of the first things to do would be to assess what is the desired behavior when  blink::IntPoint::move hits an integer behavior (clip to max value maybe?).

It should clip to max, I think.

But I thought we had shifted to saturated arithmetic for all this code. pdr@, do you know the status?

I had originally pushed for fixing this in IntPoint but it was clear that wasn't the best solution after all. Elliott, Walter, myself, Ojan and chrishtr chatted about this ~2 months ago and came to the following conclusions:
* int overflow is not innately considered a security risk.
* the worst case resulting from overflow in paint code is typically unsightly painting which is not (at least currently) sufficient to prompt code rework with maintenance/performance overhead.
* decision on whether to fix should be made on a case by case basis by those who are intimately familiar with ramifications of what would happen in their area of the code base with over/underflow.

I also looked into this and I believe it is safe. I don't think we need to fix this one.