Over to the PDF folks to take a look.

Sending over to Dan, since he fixed the original issue.

ClusterFuzz is analyzing your testcase. Developers can follow the progress at https://clusterfuzz.com/testcase?key=5099477282324480.

#6 0x55555d07c979 CCodec_FlateModule::FlateOrLZWDecode()
#7 0x55555d035881 FPDFAPI_FlateOrLZWDecode()
#8 0x55555d035c4e PDF_DataDecode()
#9 0x55555d0325b2 CPDF_StreamAcc::LoadAllData()
#10 0x55555cffb4cd CPDF_ContentParser::CPDF_ContentParser()
#11 0x55555d001443 CPDF_Page::ParseContent()
#12 0x55555cfc51b1 FPDF_LoadPage
#13 0x55555cfac27b chrome_pdf::PDFiumPage::GetPage()
#14 0x55555cfada1f chrome_pdf::PDFiumPage::GetPageFeatures()
#15 0x55555cf99761 chrome_pdf::PDFiumEngine::CalculateVisiblePages()
#16 0x55555cf8e931 chrome_pdf::OutOfProcessInstance::OnGeometryChanged()
#17 0x55555cf907c5 chrome_pdf::OutOfProcessInstance::DocumentSizeUpdated()
#18 0x55555cf9aedd chrome_pdf::PDFiumEngine::LoadPageInfo()
#19 0x55555cfa2981 chrome_pdf::PDFiumEngine::ContinueLoadingDocument()
#20 0x55555cf9b337 chrome_pdf::PDFiumEngine::LoadDocument()
#21 0x55555cfa730a chrome_pdf::DocumentLoader::ReadComplete()
#22 0x55555cf4877a pp::CompletionCallbackFactory<>::CallbackData<>::Thunk()
#23 0x55555cf4877a pp::CompletionCallbackFactory<>::CallbackData<>::Thunk()
#24 0x55555a69aaa8 ppapi::TrackedCallback::Run()
#25 0x55555a69b0c1 ppapi::internal::RunWhileLockedHelper<>::CallWhileLocked()
#26 0x55555a69b162 _ZN4base8internal7InvokerINS0_9BindStateIPFvNSt3__110unique_ptrIN5ppapi8internal20RunWhileLockedHelperIFvvEEENS3_14default_deleteIS9_EEEEEJNS0_13PassedWrapperISC_EEEEES8_E3RunEPNS0_13BindStateBaseE
#27 0x55555927138f base::debug::TaskAnnotator::RunTask()
#28 0x55555928aba7 base::MessageLoop::RunTask()
#29 0x55555928b0a8 base::MessageLoop::DoWork()
#30 0x55555928d1ea base::MessagePumpDefault::Run()
#31 0x5555592acf25 base::RunLoop::Run()
#32 0x555558eedec3 content::PpapiPluginMain()
#33 0x555558fab651 content::RunZygote()
#34 0x555558fac8c5 content::ContentMainRunnerImpl::Run()
#35 0x555558fb5b3f service_manager::Main()
#36 0x555558fab381 content::ContentMain()
#37 0x5555578611ce ChromeMain
#38 0x7ffff1c83830 __libc_start_main
#39 0x55555786102a _start

This is crashing due to out of memory. It's attempting to allocate 4G of memory.

#2  0x00000000021d4e99 in FX_OutOfMemoryTerminate () at ../../core/fxcrt/fx_memory.cpp:48
#3  0x000000000214b9be in FX_AllocOrDie (num_members=4294967295, member_size=1) at ../../core/fxcrt/fx_memory.h:70
#4  0x000000000245da82 in (anonymous namespace)::FlateUncompress (src_buf=0x384f33004010 "x\234\354\301\201", src_size=4174514, orig_size=0, 
    dest_buf=@0x7fffffffb498: 0x0, dest_size=@0x7fffffffb494: 4294967295, offset=@0x7fffffffb108: 4174514)
    at ../../core/fxcodec/codec/fx_codec_flate.cpp:558
#5  0x000000000245cc95 in CCodec_FlateModule::FlateOrLZWDecode (this=0x2fac340, bLZW=false, src_buf=0x384f33004010 "x\234\354\301\201", 
    src_size=4174514, bEarlyChange=true, predictor=0, Colors=0, BitsPerComponent=0, Columns=0, estimated_size=0, dest_buf=0x7fffffffb498, 
    dest_size=0x7fffffffb494) at ../../core/fxcodec/codec/fx_codec_flate.cpp:796


tsepez@ you added the comment: 

 // The TotalOut size returned from the library may not be big enough to
 // handle the content the library returns. We can only handle items
 // up to 4GB in size.

Is this the expected behaviour in this case?

Passing to hnakashima@ to triage for PE.

Uh... why is this PE? Isn't this a security bug?

I don't think this is a security issue. We're intentionally aborting due to the large allocation request. The question is, do we want to try to handle this large allocation, determine earlier we can't support it, do something else, or do nothing?

The comment says we can only handle items up to 4GB, but in reality even 2GB causes this crash, although 1GB does not.

Given FX_Alloc has the behavior of dying when asked to allocate too much, there isn't anything we can do apart from tightening the check.

Tom, need advice on what to do here. This CL fixes the issue, but 1GB is sort of an artificial limit...

https://pdfium-review.googlesource.com/c/pdfium/+/24730

1GB should be enough for anyone :) ... I'm ok with that.

The following revision refers to this bug:
  https://pdfium.googlesource.com/pdfium/+/6ec142da3f9cccb60a4d983ee7132c41a0798e24

commit 6ec142da3f9cccb60a4d983ee7132c41a0798e24
Author: Henrique Nakashima <hnakashima@chromium.org>
Date: Mon Feb 05 22:28:22 2018

Limit dest buffer to 1GB in FlateOrLZWDecode.

Bug:  chromium:802094 
Change-Id: I99d2d75cd431afe1cdb966e1431143ab43dd9a73
Reviewed-on: https://pdfium-review.googlesource.com/24730
Reviewed-by: Tom Sepez <tsepez@chromium.org>
Commit-Queue: Henrique Nakashima <hnakashima@chromium.org>

[modify] https://crrev.com/6ec142da3f9cccb60a4d983ee7132c41a0798e24/core/fxcodec/codec/fx_codec_flate.cpp