Created attachment 16847 [details] jpeg file to reproduce the bug fz_load_jpeg contains a heap-overflow caused due to the usage of an uninitialized variable. Under the worst circumstances, this vulnerability could cause remote code execution. To cause a denial of service an attacker is required to induce a victim to open a malicious jpeg image file. To cause a heap overflow an attacker is required to have some control of the stack before calling the fz_load_jpeg function. This control does not require a vulnerability in the calling code as it can be a reasonable side-effect of any function called before fz_load_jpeg that manipulates user input (litters the stack with data). Since Mupdf is used as an SDK, this situation is quite plausible. Explanation: Commit https://github.com/ArtifexSoftware/mupdf/commit/7d52765c5b8a5c76e459d148cd94dbaf51e562ec removed a "default" else on cinfo.output_component. if cinfo.output_component does not fit to any of the checks, colorspace will remain uninitialized. Under certain circumstances, colorspace can remain uninitialized when returned from extract_icc_profile as well. The pointer to the struct is subsequently passed to additional functions that fail to ensure that bounds are valid. The end result is that arbitrary memory can be written on the heap. To reproduce: compile a program that uses fz_load_jpeg on data from the attached file. Tested on 64 bit linux and 32 bit windows
Use CVE-2019-7321
Ocular inspection reveals that I made a mistake in my earlier commit. In addition it is possible to get ASAN to trigger on the unintialized colorspace pointer. I have a tentative patch that is being tested at the moment, next it should be reviewed before being committed.
Fixed in commit commit 2be83b57e77938fddbb06bdffb11979ad89a9c7d Author: Sebastian Rasmussen <sebras@gmail.com> Date: Tue Feb 5 03:31:29 2019 +0100 Bug 700560: Avoid dereferencing wild colorspace pointer. Thanks to Erez for reporting.