dsinclair/kcwu: this has the same regression range as  issue 743135 . Could you please have a look? Thanks!

dsinclair: Uh oh! This issue still open and hasn't been updated in the last 14 days. This is a serious vulnerability, and we want to ensure that there's progress. Could you please leave an update with the current status and any potential blockers?

If you're not the right owner for this issue, could you please remove yourself as soon as possible or help us find the right one?

If the issue is fixed or you can't reproduce it, please close the bug. If you've started working on a fix, please set the status to Started.

Thanks for your time! To disable nags, add the Disable-Nags label.

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

dsinclair: Uh oh! This issue still open and hasn't been updated in the last 28 days. This is a serious vulnerability, and we want to ensure that there's progress. Could you please leave an update with the current status and any potential blockers?

If you're not the right owner for this issue, could you please remove yourself as soon as possible or help us find the right one?

If the issue is fixed or you can't reproduce it, please close the bug. If you've started working on a fix, please set the status to Started.

Thanks for your time! To disable nags, add the Disable-Nags label.

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

hnakashima@ can you take a look?

This is a bug in _cmsQuickFloor() in lcms2_internal.h

Passing a value of 0.999998 (0x3f7fffe6) in 32-bit float to that function results in 1 rather than 0. This is happening with any 32-bit float between and including 0x3f7fff80 and 0x3f7fffff.

Using the naive floor version (the one enabled by CMS_DONT_USE_FAST_FLOOR) fixes the crash.

_cmsQuickFloor() takes a 64-bit float as argument, so it makes more sense to specify the bounds AFTER the conversion to get the bug.

input (0.999992) (3fefffefffffffff)
temp.val (103079215104.999985) (423800000000ffff)
temp.halves (65535) (1110966272)
calculated (0)

input (0.999992) (3feffff000000000)
temp.val (103079215105.000000) (4238000000010000)
temp.halves (65536) (1110966272)
calculated (1)

This method is described at http://stereopsis.com/sree/fpu2006.html as a trick that offers performance in trade-off for accuracy, so the real problem is using it in lcms relying on its correctness.

Does look like a dup, redoing CF to make sure it says it's fixed.

ClusterFuzz has detected this issue as fixed in range 497463:497522.

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

Fuzzer: libFuzzer_pdf_codec_icc_fuzzer
Job Type: libfuzzer_chrome_asan
Platform Id: linux

Crash Type: Heap-buffer-overflow READ 4
Crash Address: 0x60800000078c
Crash State:
  TetrahedralInterpFloat
  _LUTevalFloat
  XFormSampler16
  
Sanitizer: address (ASAN)

Recommended Security Severity: Medium

Regressed: https://clusterfuzz.com/revisions?job=libfuzzer_chrome_asan&range=420440:420580
Fixed: https://clusterfuzz.com/revisions?job=libfuzzer_chrome_asan&range=497463:497522

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

See https://chromium.googlesource.com/chromium/src/+/master/testing/libfuzzer/reproducing.md for more information.

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

This bug has been closed for more than 14 weeks. Removing security view restrictions.

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