Open Bug 1374945 Opened 7 years ago Updated 2 years ago

stack exhaustion loading pdf


(Firefox :: PDF Viewer, defect, P3)

30 Branch



Tracking Status
firefox-esr52 --- wontfix
firefox57 --- wontfix
firefox58 --- wontfix
firefox59 --- wontfix
firefox60 --- wontfix


(Reporter: Laraweron, Unassigned)




(4 keywords, Whiteboard: [sg:dos][pdfjs-image-jpx])


(1 file)

2.29 KB, application/pdf
Attached file poc.pdf
User Agent: Mozilla/5.0 (Windows NT 6.1; rv:55.0) Gecko/20100101 Firefox/55.0
Build ID: 20170619071723

Steps to reproduce:

Open Poc.pdf

Actual results:

Crash reports:
Component: Untriaged → PDF Viewer
Keywords: crash
I see the memory grows fast but does not see a crash.
Group: firefox-core-security
Severity: normal → critical
Keywords: csectype-dos
Looks like the reporter has 2GB of memory, a lot less than our developer machines. Could easily believe he's run out of stack space on a testcase where we wouldn't.
Group: firefox-core-security
Keywords: testcase
Summary: stack overflow PDFium → stack exhaustion PDFium
Whiteboard: [sg:dos]
I'm not sure why the above is tagged as PDFium as this seems to be a pdf.js issue.
Priority: -- → P5
Summary: stack exhaustion PDFium → stack exhaustion loading pdf
Raphel, can you still reproduce using a current version?
Flags: needinfo?(Laraweron)
Has STR: --- → yes
Ever confirmed: true
Flags: needinfo?(Laraweron)
Keywords: crashcsectype-oom
OS: Unspecified → Windows
Hardware: Unspecified → All
Version: 55 Branch → 31 Branch
Regression range:

0c2a1ea6a296	Yury Delendik — Bug 979909 - Update pdf.js to version 0.8.1114. r=Mossop
Has Regression Range: --- → yes
Keywords: regression
Version: 31 Branch → 30 Branch
nice find
Blocks: 979909
Too late to fix for 58. If anyone comes up with a fix, we can take a patch in Nightly (currently 60)

Still causes a pretty big memory spike on load, but the usage goes down pretty quickly again once it finishes loading.

No longer blocks: 979909
Severity: critical → --
Priority: P5 → --
Regressed by: 979909
Severity: -- → S3
Priority: -- → P3

(In reply to Ryan VanderMeulen [:RyanVM] from comment #9)

Still causes a pretty big memory spike on load, but the usage goes down pretty quickly again once it finishes loading.

I can still reproduce this on Linux in Nightly 97.
Brendan can reproduce this on Mac in Nightly 97.
Calixte can reproduce this on Windows in ESR 91, can't reproduce this on Windows in Nightly 97.

WIth Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:100.0) Gecko/20100101 Firefox/100.0

it is loading for several minutes (until I stopped the tab). In the first 60 sec of loading the memory usage comes up to about 2-2.5 GB.

I also could not find a different behaviour in the release before the regression, mentioned above.

but the poc.pdf contains a JPX coded image with W=32765 and H=32765 with 8 BPP. (Info from Acrobat), while the object browser tells me:

XObject (dict)
    Im0 (stream) [id: 5, gen: 0]
        BitsPerComponent = 8
        ColorSpace = /DeviceGray
        Filter (array)
        Height = 57
        Length = 1402
        Subtype = /Image
        Type = /XObject
        Width = 1200
Whiteboard: [sg:dos] → [sg:dos][pdfjs-image-jpx]
You need to log in before you can comment on or make changes to this bug.