Hi, I've had a look at CVE-2018-6544 in mupdf, and after some investigations I think that we can reasonably consider the Wheezy version as unaffected by this issue and mark it no-dsa.
The issue is not reproducible with Valgrind in wheezy. I couldn't build the Wheezy version of mupdf with asan in Jessie because the codebase isn't compatible with the dependencies (looks like an api break in libopenjpeg). However, analysis of the patches suggests that the code present in Wheezy isn't completely affected by the issue. One could describe CVE-2018-6544 as composed of two separate issues, one triggering the other: * Concerning the first one: In pdf_open_raw_filter (pdf-stream.c), a full exception stack could lead the catch block to be executed before fz_keep_stream(ctx, chain), leading to fz_drop_stream free-ing data that would actually be needed later ('keep' should really be called before 'drop' in this case). This may lead heap-use-after-free bugs later. If I understand the code well, mupdf in Wheezy isn't affected by this issue because: - it doesn't call fz_drop_stream at all in the failure case (actually this function doesn't exists in the 0.9 branch, at that time it was named fz_close). In fact, while the more recent versions execute fz_keep_stream in a codebase specific try block (with fz_drop_stream in the catch), the 0.9 version handles errors by looking at the return value and exiting if necessary. - fz_keep_stream(ctx, chain) is called at the beginning of the function and I can't see any reason why the stream would be freed before keep is called. * Concerning the second part: Because of buggy exception handling in pdf-xref.c, mupdf could enter in an "infinite" error-handling recursion only bounded by the exception stack. This bug would then trigger the previously discussed case where the try block is called with a full exception stack, leading to direct execution of the catch block and freeing of actually needed data. I'm still quite unsure on whether the Wheezy version is affected by the second part of this issue or not because the code is quite different and error handling has changed a lot. I'd say it is not impossible that wheezy is affected by this issue. However, IMO if the first part of the issue (the actual heap-use-after-free) isn't affecting Wheezy, then there's no real need to care about this issue which, in the worst case, could maybe crash mupdf (but I'm not even sure of that) and I'm not convinced that taking so much time to fix and test it would be the right way to use my assigned time. :) If anybody wants to have a look, feel free to do so, otherwise I'll mark this issue no-dsa (I'd rather avoid 'not-affected' since I'm not 100% sure of that and I think it's not worth taking any more time for this issue). Regards, Hugo  http://git.ghostscript.com/?p=mupdf.git;h=b03def134988da8c800adac1a38a41a1f09a1d89  http://git.ghostscript.com/?p=mupdf.git;h=26527eef77b3e51c2258c8e40845bfbc015e405d  http://git.ghostscript.com/?p=mupdf.git;a=commit;h=681039767f2ccc72e236246178893eb0989169c9 -- Hugo Lefeuvre (hle) | www.owl.eu.com 4096/ 9C4F C8BF A4B0 8FC5 48EB 56B8 1962 765B B9A8 BACA
Description: PGP signature