It was reported [1],[2] that OpenJPEG suffered from a bug where, in the case of corrupt files, tiles were failing to be properly allocated, which left the code attempting to work with non-existent tiles. Due to the lack of error checking, the code would later access the contents of the uninitialized memory and would cause a segfault. A patch has been posted to the ghostscript git, for an embedded copy of OpenJPEG, to correct this flaw. [3] [1] http://bugs.ghostscript.com/show_bug.cgi?id=693171 [2] http://code.google.com/p/openjpeg/issues/detail?id=159 [3] http://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=29a16f87849a874cd872fc8e2beab2b3986eea51;hp=514595fc2cc84f51efdef563cf7a35a0050902e5
The bug report does not indicate whether or not arbitrary code execution via a crafted PDF (in the context of upstream ghostscript, or in Poppler since we use libopenjpeg there) or jpeg file is possible. Since I can't tell, I've filed the bug -- it could very well be nothing (a crash of the viewer linked to openjpeg), but I didn't want to rule it out before having it looked at.
Based on the reproducers and the analysis of the patches, it seems openjpeg crashes due to out-of-bounds read. There is no scope of arbitrary code execution and this can only lead to denial of service i.e. application crash. We do not consider this as a security issue.