pdfium needs to throw on oom and not encounter dos condition. (oom while decompressing open jpeg image's embeded in a pdf).
Reported by
ak4...@gmail.com,
Feb 7 2018
|
||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.140 Safari/537.36 Steps to reproduce the problem: 1. open the attached pdf in chrome. 2. 3. What is the expected behavior? terminate the thread because of high memory usage. What went wrong? pdfium cannot unpack the image given the length parameters and consumes up to 20 gb of virtual memory. it can crash the desktop. i did not test this on android but i guess that the effect will be greater with fewer ram. i did test it in chrome stable 64 on ubuntu 16.4.03 & win rs3. Crashed report ID: no How much crashed? Whole browser Is it a problem with a plugin? No Did this work before? N/A Chrome version: 64.0.3282.140 Channel: stable OS Version: 10.0 Flash Version: regards.
,
Feb 7 2018
Where did you see the "20 gb of virtual memory" usage? I tested on 64-bit Window and Linux. The PDF plugin is limited to 2 or 3 GB of memory usage. On both OSes, the PDF plugin hits the limit and crashes with Out Of Memory. i.e. As far as I can tell, everything is working properly and there is no bug. On Android, there is no Chrome PDF Viewer. If you see an issue there with the native PDF viewer, file a bug on their bug tracker.
,
Feb 8 2018
,
Feb 10 2018
yes sorry, my mistake this is oom (that is a bug by itself), i don't believe that this is exploitable so i did not investigate any further. sorry for the confusion. regards.
,
Feb 10 2018
Thank you for providing more feedback. Adding requester "thestig@chromium.org" to the cc list and removing "Needs-Feedback" label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Feb 12 2018
ak44yn@ as per comment #4 shall we close this issue.
,
Feb 12 2018
|
||||||
►
Sign in to add a comment |
||||||
Comment 1 by davidben@chromium.org
, Feb 7 2018