Bugzilla – Bug 1205486
VUL-0: CVE-2022-43295: xpdf: pdftotext crash
Last modified: 2023-02-20 12:58:31 UTC
XPDF v4.04 was discovered to contain a stack overflow via the function
FileStream::copy() at xpdf/Stream.cc:795.
Created attachment 862922 [details]
So far I was not able to reproduce the issue and to catch a memory leak.
$ valgrind -s --leak-check=full pdftotext reproducer.pdf
==25981== HEAP SUMMARY:
==25981== in use at exit: 2,112 bytes in 19 blocks
==25981== total heap usage: 6,994 allocs, 6,975 frees, 977,025 bytes allocated
==25981== LEAK SUMMARY:
==25981== definitely lost: 0 bytes in 0 blocks
==25981== indirectly lost: 0 bytes in 0 blocks
==25981== possibly lost: 0 bytes in 0 blocks
==25981== still reachable: 2,112 bytes in 19 blocks
==25981== suppressed: 0 bytes in 0 blocks
==25981== Reachable blocks (those to which a pointer was found) are not shown.
==25981== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==25981== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
It's a bit unclear if the poppler pdftotext tool is in deed affected. No fix is available yet.
Upstream does not intend to fix this issue with a patch but rather with a general re-write of xpdf:
> That's a loop in the PDF object structure.
> I'm working on a more robust loop detector for Xpdf 5.
I cannot reproduce the exploit. When given the crafted PDF file, pdftotext from poppler aborts with an error. There is no crash and no segmentation fault. This bug appears to affect only xpdf -- which we don't ship. I think this can be closed.