No fix for this issue exists. Upstream said that they'll "work on it" about 1 year ago. No observable progress has been made since then.

Testcase renamed to:

https://github.com/skysider/FuzzVuln/blob/master/xpdf_pdftohtml_large_loop_JBIG2Stream_readSymbolDictSeg.pdf

couln't reproduce a large loop anywhere, there's a segfault only in 12/poppler:

Program received signal SIGSEGV, Segmentation fault.
XRef::getNumEntry (this=0x0, offset=6803) at XRef.cc:1303
1303	  if (size > 0)
Missing separate debuginfos, use: zypper install fontconfig-debuginfo-2.11.0-6.1.x86_64 libbz2-1-debuginfo-1.0.6-30.14.1.x86_64 libexpat1-debuginfo-2.1.0-21.28.1.x86_64 libfreetype6-debuginfo-2.5.5-7.5.1.x86_64 libgcc_s1-debuginfo-12.2.1+git416-1.5.1.x86_64 libjbig2-debuginfo-2.0-12.13.x86_64 libjpeg8-debuginfo-8.1.2-31.28.1.x86_64 liblcms2-2-debuginfo-2.5-4.20.x86_64 liblzma5-debuginfo-5.0.5-6.7.1.x86_64 libpng16-16-debuginfo-1.6.8-15.5.2.x86_64 libstdc++6-debuginfo-12.2.1+git416-1.5.1.x86_64 libtiff5-debuginfo-4.0.9-44.68.1.x86_64 libz1-debuginfo-1.2.8-6.3.1.x86_64
(gdb) bt
#0  XRef::getNumEntry (this=0x0, offset=6803) at XRef.cc:1303
#1  0x00007ffff79483ee in Lexer::getObj (this=0x457810, obj=obj@entry=0x4575b8, cmdA=cmdA@entry=0x7ffff79d7e08 "endstream", objNum=objNum@entry=0) at Lexer.cc:594
#2  0x00007ffff795299d in Parser::shift (this=this@entry=0x457590, cmdA=cmdA@entry=0x7ffff79d7e08 "endstream", objNum=objNum@entry=0) at Parser.cc:323
#3  0x00007ffff7952b7e in Parser::makeStream (this=this@entry=0x457590, dict=dict@entry=0x7fffffffe4c0, fileKey=fileKey@entry=0x0, encAlgorithm=encAlgorithm@entry=cryptRC4, 
    keyLength=keyLength@entry=0, objNum=objNum@entry=0, objGen=objGen@entry=0, recursion=recursion@entry=1, strict=strict@entry=false) at Parser.cc:245
#4  0x00007ffff7953258 in Parser::getObj (this=this@entry=0x457590, obj=obj@entry=0x7fffffffe4c0, simpleOnly=simpleOnly@entry=false, fileKey=fileKey@entry=0x0, 
    encAlgorithm=encAlgorithm@entry=cryptRC4, keyLength=keyLength@entry=0, objNum=objNum@entry=0, objGen=objGen@entry=0, recursion=recursion@entry=0, strict=strict@entry=false)
    at Parser.cc:131
#5  0x00007ffff7965b8c in XRef::readXRef (this=this@entry=0x457220, pos=pos@entry=0x4572b8, followedXRefStm=followedXRefStm@entry=0x7fffffffe520, 
    xrefStreamObjsNum=xrefStreamObjsNum@entry=0x0) at XRef.cc:551
#6  0x00007ffff7965da9 in XRef::XRef (this=0x457220, strA=0x457050, pos=<optimized out>, mainXRefEntriesOffsetA=0, wasReconstructed=0x7fffffffe59f, reconstruct=<optimized out>)
    at XRef.cc:342
#7  0x00007ffff7956ecf in PDFDoc::setup (this=this@entry=0x456f80, ownerPassword=ownerPassword@entry=0x0, userPassword=userPassword@entry=0x0) at PDFDoc.cc:262
#8  0x00007ffff79570f8 in PDFDoc::PDFDoc (this=0x456f80, fileNameA=<optimized out>, ownerPassword=0x0, userPassword=0x0, guiDataA=<optimized out>) at PDFDoc.cc:167
#9  0x00007ffff794ba35 in LocalPDFDocBuilder::buildPDFDoc (this=<optimized out>, uri=..., ownerPassword=0x0, userPassword=0x0, guiDataA=0x0) at LocalPDFDocBuilder.cc:31
#10 0x0000000000406c06 in main (argc=2, argv=0x7fffffffe838) at pdftohtml.cc:242
(gdb) 

[another issue, probably]

I think porting

    if (unlikely(symHeight > 0x40000000)) {
      error(errSyntaxError, curStr->getPos(), "Bad height value in JBIG2 symbol dictionary");
      goto syntaxError; 
    }

to 11sp1/poppler plus fixing the segfault in 12/poppler could do the job.

(will do later)

(In reply to Petr Gajdos from comment #4)
> (will do later)

(In reply to Petr Gajdos from comment #3)
> I think porting
> 
>     if (unlikely(symHeight > 0x40000000)) {
>       error(errSyntaxError, curStr->getPos(), "Bad height value in JBIG2
> symbol dictionary");
>       goto syntaxError; 
>     }
> 
> to 11sp1/poppler plus fixing the segfault in 12/poppler could do the job.

However, 11sp1/poppler is not maintained anymore. If my assumptions are correct, only (probably unrelated to this CVE) segfault in 12/poppler remains.

Segfault fixed in sr#301260.
If I should supplement the submission somehow, let me know.

(In reply to Petr Gajdos from comment #2)
> 12/poppler:
> 
> [..]
> [another issue, probably]

I can not confirm this crash with 0.24.4 (unpatched). 

Just to compare my setup, what kind of resources did the machine have where this was tested? Wondering if it might be a side effect of missing resources?

(In reply to Robert Frohl from comment #8)
> (In reply to Petr Gajdos from comment #2)
> > 12/poppler:
> > 
> > [..]
> > [another issue, probably]
> 
> I can not confirm this crash with 0.24.4 (unpatched). 

I can not either. To exclude that it was an intermediate state in my local copy, I have disabled all patches and then enable it patch by patch, I do not see any crash. Perhaps I might had used a wrong testcase for example given testcases was renamed in github repo.

Sorry for noise then. I think the final conclusion could be that no our poppler code stream is affected. Right?

closing: after closer investigation non of our version are affected.