Invalid PDF input causes SIGSEGV crash

[mhassan1]

I noticed that certain invalid PDFs cause the Node.js process to crash with SIGSEGV. I will reach out with examples.

Even though it is an invalid PDF, it should not cause the Node.js process to crash with SIGSEGV, which can't be caught; instead, it should throw an Error, like it does for other invalid PDFs.

[julianhille]

I found some of f them here and there and fixed them and always wanted to also do a PR against the Origin of PDF writer. We should try there first and if this is not working o fork it

[mhassan1]

PDF Writer is deprecated and I wonder if they will accept a pull request. Also, haven't we already forked PDF Writer here?

A crash like this seems like it should be accompanied by a CVE, since it can cause DOS.

[julianhille]

I've seen some updates some weeks ago over there.
That is why #202 exists.

[julianhille]

Btw #189 was one of those nope exceptions

[julianhille]

Can you attach some of these broken files which trigger issues or send them to me we could both hunt those bugs if you want

[mhassan1]

I can send an example of a broken file to you directly.

I will look at 4.1 to see if this crash exists there.

[mhassan1]

I've pulled in PDF-Writer 4.1, and it's the same issue. It also reproduces in hummus.

Here is the output:

Signal received: 11, errno: 0
  SIGSEGV @ 0x0x10
################################################################################
Stack trace:
################################################################################
1   aws-crt-nodejs.node                 0x0000000109f78d63 s_print_stack_trace + 19
2   libsystem_platform.dylib            0x00007ff806b43dfd _sigtramp + 29
3   ???                                 0x00000003bf87b700 0x0 + 16098244352
4   muhammara.node                      0x000000010a53c7d4 _ZN9PDFParser21ParseLastXrefPositionEv + 244
5   muhammara.node                      0x000000010a53c080 _ZN9PDFParser15StartPDFParsingEP23IByteReaderWithPositionRK17PDFParsingOptions + 144
6   muhammara.node                      0x000000010a52e4d7 _ZN18PDFDocumentHandler19StartCopyingContextEP23IByteReaderWithPositionRK17PDFParsingOptions + 87
7   muhammara.node                      0x000000010a52aa6f _ZN25PDFDocumentCopyingContext5StartERKNSt3__112basic_stringIcNS0_11char_traitsIcEENS0_9allocatorIcEEEEPN9PDFHummus15DocumentContextEP14ObjectsContextRK17PDFParsingOptionsP18IPDFParserExtender + 79
8   muhammara.node                      0x000000010a507684 _ZN9PDFHummus15DocumentContext23CreatePDFCopyingContextERKNSt3__112basic_stringIcNS1_11char_traitsIcEENS1_9allocatorIcEEEERK17PDFParsingOptions + 68
9   muhammara.node                      0x000000010a4c690e _ZN15PDFWriterDriver23CreatePDFCopyingContextERKN2v820FunctionCallbackInfoINS0_5ValueEEE + 1070
10  node                                0x00000001050aa539 _ZN2v88internal25FunctionCallbackArguments4CallENS0_15CallHandlerInfoE + 265
11  node                                0x00000001050aa006 _ZN2v88internal12_GLOBAL__N_119HandleApiCallHelperILb0EEENS0_11MaybeHandleINS0_6ObjectEEEPNS0_7IsolateENS0_6HandleINS0_10HeapObjectEEESA_NS8_INS0_20FunctionTemplateInfoEEENS8_IS4_EENS0_16BuiltinArgumentsE + 550
12  node                                0x00000001050a977f _ZN2v88internal21Builtin_HandleApiCallEiPmPNS0_7IsolateE + 255
13  node                                0x000000010591e3f9 Builtins_CEntry_Return1_DontSaveFPRegs_ArgvOnStack_BuiltinExit + 57

I believe we should report this to Snyk here. What do you think?

[julianhille]

added a fix, a regression test and reported it to snyk togehter with the npe from before. if tests running through i'll release a new version.
Even added a backport for 2.x

[julianhille]

Thank you very much for reporting it.