From 776ee05584156f6737ec7603b2f2f68d3a301bab Mon Sep 17 00:00:00 2001 From: Robin Watts Date: Fri, 17 Jan 2014 13:40:17 +0000 Subject: Bug 694896: Ensure that repairs don't lose trailer dict. When we find certain classes of flaw in the file while attempting to read an object, we trigger an automatic repair of the file. This leaves almost all objects unchanged; the sole exception is that of the trailer object (and its sub objects) which can get dropped and recreated. To avoid leaving people holding handles to objects within the trailer dict high and dry, we introduce a 'pre_repair_trailer' object to each xref entry. On a repair, we copy the existing trailer object to this. As we only ever repair once, this is safe. The only known place where this is a problem is when setting up the pdf_crypt for a document; we adapt the code here to allow for potential problems. The example file that shows this up is: 048d14d2f5f0ae31e9a2cde0be66f16a_asan_heap-uaf_86d4ed_3961_3661.pdf Thanks to Mateusz Jurczyk and Gynvael Coldwind of the Google Security Team for providing the fuzzing files. --- include/mupdf/pdf/xref.h | 1 + 1 file changed, 1 insertion(+) (limited to 'include/mupdf/pdf/xref.h') diff --git a/include/mupdf/pdf/xref.h b/include/mupdf/pdf/xref.h index de53da7c..f9e1657f 100644 --- a/include/mupdf/pdf/xref.h +++ b/include/mupdf/pdf/xref.h @@ -47,6 +47,7 @@ struct pdf_xref_s int len; pdf_xref_entry *table; pdf_obj *trailer; + pdf_obj *pre_repair_trailer; }; void pdf_cache_object(pdf_document *doc, int num, int gen); -- cgit v1.2.3