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 164 of file fx_dib_transform.cpp, which is stack frame 0.

@Dan Sinclair: Request you to please take a look into it. Please help us to reassign if not with respect to your change.

Thanks.!

How can I test this locally, there doesn't seem to be a build target for the given fuzzer? The file seems to be OK with pdfium_test.

This requires a UBSan build: https://www.chromium.org/developers/testing/undefinedbehaviorsanitizer

A ubsan build of chrome? There doesn't seem to be a pdf_curated fuzzer target to build.

Try building UBSAN pdfium_test inside a Chromium checkout and see if that can repro the bug. If not, you'll need a full UBSAN build of chrome.

The image transformer's huge numbers comes from this part of the PDF:

/FontMatrix [
    0.0111111
    13314
    0
    -0.0111111
    0
    0
  ]

which is part of 

%% Original object ID: 62 0
46 0 obj

(around line 7367 as disassembled by qpdf)

In particular, matrix.b is scaled by the font size

/R17 10.8122 Tf

and then by the glyph's image matrix:

q 24 0 0 -65 9 5 cm    # around line 9024

By the time CFX_ImageTransformer is called, m_pMatrix.b has ballooned to -3454886.25

This sets stretch_width to 3454887  (fx_dib_transformer.cpp, line 385)

which causes m_dest2stretch.a to be set to 1198261.63

The bilerp wants to transform a bitmap 4 pixels wide and 3454895 pixels high.
Since the implementation for the matrix is integral, and the matrix contains
(306754976, 314265856) for matrix.a and matrix.b the resulting multiplication
needs 51 bits to represent the answer.

One solution for now would be to preflight the worst multiplication (e.g.

max((int64_t) m_result.Width() * result2stretch_fix.a, 
    (int64_t) m_result.Height() * result2stretch_fix.b) ... etc

and see if the intermediates fit within 30 bits.

 

That sounds similar to what the patch is doing now, I'm just using our safe math libraries to check the calculations.

I've arbitrarily decided that if the calculation fails to use 0 as the result.

Would you be open to doing the checking outside the loop instead of inside the loop?

Ah, I see. I though you were saying to do the calculations inside Transform, but you're saying move them out to CFX_ImageTransformer::Continue.

Moving them out would be fine.

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

ClusterFuzz has detected this issue as fixed in range 467403:467472.

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

Fuzzer: tokenfuzz_pdf_curated
Job Type: linux_ubsan_chrome
Platform Id: linux

Crash Type: Integer-overflow
Crash Address: 
Crash State:
  CFX_BilinearMatrix::Transform
  CFX_ImageTransformer::Continue
  CFX_DIBSource::TransformTo
  
Sanitizer: undefined (UBSAN)

Regressed: https://clusterfuzz.com/revisions?job=linux_ubsan_chrome&range=379730:379778
Fixed: https://clusterfuzz.com/revisions?job=linux_ubsan_chrome&range=467403:467472

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


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

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