No CL in the regression range changes the crashed files. The result is the blame information.

Author: John Abd-El-Malek
Project: chromium-pdfium
Changelist: https://pdfium.googlesource.com/pdfium.git/+/5110c4743751145c4ae1934cd1d83bc6c55bb43f
Time: Sat May 17 22:33:34 2014 -0700
The CL last changed line 1812 of file cmspack.c, which is stack frame 0.

Author: John Abd-El-Malek
Project: chromium-pdfium
Changelist: https://pdfium.googlesource.com/pdfium.git/+/5110c4743751145c4ae1934cd1d83bc6c55bb43f
Time: Sat May 17 22:33:34 2014 -0700
The CL last changed line 411 of file cmsxform.c, which is stack frame 1.

Author: Dan Sinclair
Project: chromium-pdfium
Changelist: https://pdfium.googlesource.com/pdfium.git/+/764ec513eecbebd12781bcc96ce81ed5e736ee92
Time: Mon Mar 14 13:35:12 2016 -0400
The CL last changed line 215 of file fx_codec_icc.cpp, which is stack frame 2.

Author: dan sinclair
Project: chromium-pdfium
Changelist: https://pdfium.googlesource.com/pdfium.git/+/61b2fc718910a5ab2a75ec5026b239ff33bccfdc
Time: Wed Mar 23 19:21:44 2016 -0400
The CL last changed line 873 of file cpdf_colorspace.cpp, which is stack frame 3.

Author: dan sinclair
Project: chromium-pdfium
Changelist: https://pdfium.googlesource.com/pdfium.git/+/61b2fc718910a5ab2a75ec5026b239ff33bccfdc
Time: Wed Mar 23 19:21:44 2016 -0400
The CL last changed line 139 of file cpdf_color.cpp, which is stack frame 4.

Author: tsepez
Project: chromium-pdfium
Changelist: https://pdfium.googlesource.com/pdfium.git/+/b5e8f14e3eefc5da995b332788d3203cee204883
Time: Fri Mar 25 15:18:35 2016 -0700
The CL last changed line 42 of file cpdf_colorstate.cpp, which is stack frame 5.

Author: Dan Sinclair
Project: chromium-pdfium
Changelist: https://pdfium.googlesource.com/pdfium.git/+/764ec513eecbebd12781bcc96ce81ed5e736ee92
Time: Mon Mar 14 13:35:12 2016 -0400
The CL last changed line 1050 of file fpdf_page_parser.cpp, which is stack frame 6.

Suspected Project: chromium-pdfium
========================================
Unable to find suspect from findit.

Through code search file 'task_annotator.cc' suspecting the below:
https://chromium.googlesource.com/chromium/src/+/ad8fb459e07068582588d72fd5dabdb72e70b689%5E%21/base/debug/task_annotator.cc

skyostil@@ Could you please look into this issue if its related to your change,else please re assign it to an appropriate dev person.

Thanks,

Sorry, my task annotator refactoring doesn't have anything to do with this bug.

Adding a randomly chosen owner of pdfium. Bruce, do you know who looks after this code?

tsepez@ and thestig@ work on this more frequently I believe.

We may want to upgrade to lcms 2.7. (Released March 2015) I'll check to see if this problem exists there / in their git repo.

I haven't verified, but https://github.com/mm2/Little-CMS/commit/6da55e0b51124b795b707d318c0e03252222ba06 just fixed this upstream a month ago. Maybe we want to upgrade to 2.7, and apply this patch on top? Or just apply it on top of 2.6 for now? Either way, I'm not around the rest of this week to do it.

I *think* I ran into some issues while trying to upgrade lcms a while back... I'll take a look again later this week.

The following revision refers to this bug:
  https://pdfium.googlesource.com/pdfium.git/+/79d798da0d4b5f9f1fc27917102bdd7bcfbe863e

commit 79d798da0d4b5f9f1fc27917102bdd7bcfbe863e
Author: ochang <ochang@chromium.org>
Date: Fri Jun 03 17:27:22 2016

LCMS: Update FROM_16_TO_8 macro not to raise UBSan error

Cherry-picked from upstream commit 6da55e0b51124b795b707d318c0e03252222ba06

BUG= chromium:616253 

Review-Url: https://codereview.chromium.org/2034123003

[add] https://crrev.com/79d798da0d4b5f9f1fc27917102bdd7bcfbe863e/third_party/lcms2-2.6/0001-from16-to-8-overflow.patch
[modify] https://crrev.com/79d798da0d4b5f9f1fc27917102bdd7bcfbe863e/third_party/lcms2-2.6/README.pdfium
[modify] https://crrev.com/79d798da0d4b5f9f1fc27917102bdd7bcfbe863e/third_party/lcms2-2.6/src/lcms2_internal.h

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

commit f1ab43c533e64124ead62d51ded2f91ee2a51181
Author: ochang <ochang@chromium.org>
Date: Mon Jun 06 17:08:32 2016

Roll PDFium c324646..f7e108b

https://pdfium.googlesource.com/pdfium.git/+log/c324646..f7e108b

BUG= 427616 , 616253 , 616838 , 613623 
TBR=dsinclair@chromium.org

TEST=bots

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

[modify] https://crrev.com/f1ab43c533e64124ead62d51ded2f91ee2a51181/DEPS

ClusterFuzz has detected this issue as fixed in range 398017:398351.

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

Fuzzer: tokenfuzz_pdf_march16
Job Type: linux_ubsan_chrome
Platform Id: linux

Crash Type: Integer-overflow
Crash Address: 
Crash State:
  Pack3BytesSwap
  CachedXFORM
  IccLib_Translate
  
Regressed: https://cluster-fuzz.appspot.com/revisions?job=linux_ubsan_chrome&range=370022:370027
Fixed: https://cluster-fuzz.appspot.com/revisions?job=linux_ubsan_chrome&range=398017:398351

Minimized Testcase (450.51 Kb): https://cluster-fuzz.appspot.com/download/AMIfv959h_nloYMRpU-VMNL3L81_kdcdQY9Vb0m7Y8QH91ZVagSOm_jNmCCVKs_Pm3jcCDqDQj5pEFbTQrL_h-5BdwtaJKXruHjNUhG4K08sfX7K2R0DPtVALur_08dLwOkIXSsSgaSKHvJUSfmZurEZm9j2iRzML-xA8jaWBm75hqnQ-s7DSuU

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.

Given this has been around for ages, do we care to merge back to M52 / M51?

I don't think it's necessary to merge this. I'm pretty sure that in this case, there's no difference (at least on x86) in terms of the result, just that it prevents UBSan from complaining.

Note that the behavior doesn't depend so much on the processor (all processors we care about handle overflow the same way) as it does on the compiler. gcc/clang are pretty aggressive about doing optimizations based on 'impossible' scenarios and they consider integer-overflow 'impossible'. I don't know whether that applies in this case.

I think that if there is no known exploit and if the issue is not a regression then that is a reason to not merge back, but I wouldn't make that decision based on x86/x64 behavior, at least not with checking the code-gen on all platforms quite carefully.

Removing EditIssue view restrictions from ClusterFuzz filed bugs. If you believe that this issue should still be restricted, please reapply the label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot