A CVE has been requested for an upstream fix in mupdf: http://openwall.com/lists/oss-security/2016/09/22/7 The commit to fix the issue is linked near the bottom of the message. They mentioned it will be in 1.10, so maybe there was a 1.9 we missed.
Status: NEW => ASSIGNED
Found some more advisories from the same security researchers: - https://blogs.gentoo.org/ago/2016/09/22/mupdf-mutool-infinite-loop-in-gatherresourceinfo-pdfinfo-c/ - https://blogs.gentoo.org/ago/2016/09/22/mupdf-use-after-free-in-pdf_to_num-pdf-object-c/ (same as above) - https://blogs.gentoo.org/ago/2016/09/24/mupdf-mujstest-global-buffer-overflow-in-my_getline-jstest_main-c/ - https://blogs.gentoo.org/ago/2016/09/24/mupdf-mujstest-global-buffer-overflow-in-main-jstest_main-c/ - https://blogs.gentoo.org/ago/2016/09/25/mupdf-mujstest-strcpy-param-overlap-in-main-jstest_main-c/ (from https://blogs.gentoo.org/ago/advisories/)
Summary: mupdf new use-after-free security issue => mupdf new use-after-free security issue + security issues in mutool and mujstest
I'm updating mupdf to 1.9a, and adding the relevant patches. As I've fully unbundled mujs and don't package mujstest, I'll only cherry-pick the commits for the infinite loop in mutool and the use after free in pdf_to_num.
Summary: mupdf new use-after-free security issue + security issues in mutool and mujstest => mupdf new use-after-free security issue + security issues in mutool (and mujstest, but not affecting us)
I dropped the package from Cauldron for various reasons: having to unbundle mujs is messy, nothing relies on this package, the current git master HEAD generates 34 MB stripped binaries for a "lightweight" PDF reader... And there are good alternatives already packaged. Until upstream does some work on their packaging-friendliness (mujs as shared library, libmupdf as shared library, instead of both as bundled ones), this does not bring much added value to the distro, just more security burden.
Status: ASSIGNED => RESOLVEDResolution: (none) => FIXED