Created attachment 14605 [details] Pdf that causes UAF Hello, I would like to report a use after free that I have found by fuzzing. Please see attached the pdf that causes the UAF. ==10581==ERROR: AddressSanitizer: heap-use-after-free on address 0x61300000bf00 at pc 0x00000063a1eb bp 0x7ffe68854f90 sp 0x7ffe68854f88 READ of size 4 at 0x61300000bf00 thread T0 #0 0x63a1ea in fz_keep_key_storable (/usr/local/bin/mupdf-gl+0x63a1ea) #1 0x521dec in fz_new_default_colorspaces (/usr/local/bin/mupdf-gl+0x521dec) #2 0x66ae18 in pdf_load_default_colorspaces (/usr/local/bin/mupdf-gl+0x66ae18) #3 0x673ca4 in pdf_run_page_contents_with_usage (/usr/local/bin/mupdf-gl+0x673ca4) #4 0x673a11 in pdf_run_page_contents (/usr/local/bin/mupdf-gl+0x673a11) #5 0x529c41 in fz_run_page_contents (/usr/local/bin/mupdf-gl+0x529c41) #6 0x529ea6 in fz_run_page (/usr/local/bin/mupdf-gl+0x529ea6) #7 0x649a61 in fz_new_stext_page_from_page (/usr/local/bin/mupdf-gl+0x649a61) #8 0x4f0f63 in load_page (/usr/local/bin/mupdf-gl+0x4f0f63) #9 0x4f1682 in main (/usr/local/bin/mupdf-gl+0x4f1682) #10 0x7fa0f6588560 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x20560) #11 0x41c5b9 in _start (/usr/local/bin/mupdf-gl+0x41c5b9) 0x61300000bf00 is located 0 bytes inside of 368-byte region [0x61300000bf00,0x61300000c070) freed by thread T0 here: #0 0x4ba9c0 in __interceptor_cfree.localalias.0 (/usr/local/bin/mupdf-gl+0x4ba9c0) #1 0x5f0c55 in fz_free (/usr/local/bin/mupdf-gl+0x5f0c55) #2 0x79b859 in pdf_update_free_text_annot_appearance (/usr/local/bin/mupdf-gl+0x79b859) #3 0x79fb2a in pdf_update_appearance (/usr/local/bin/mupdf-gl+0x79fb2a) #4 0x78c3ee in pdf_load_annots (/usr/local/bin/mupdf-gl+0x78c3ee) #5 0x66b6c7 in pdf_load_page (/usr/local/bin/mupdf-gl+0x66b6c7) #6 0x4f0f31 in load_page (/usr/local/bin/mupdf-gl+0x4f0f31) #7 0x4f1682 in main (/usr/local/bin/mupdf-gl+0x4f1682) #8 0x7fa0f6588560 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x20560) previously allocated by thread T0 here: #0 0x4bab58 in malloc (/usr/local/bin/mupdf-gl+0x4bab58) #1 0x5f029c in fz_calloc (/usr/local/bin/mupdf-gl+0x5f029c) #2 0x502d9d in fz_new_icc_colorspace (/usr/local/bin/mupdf-gl+0x502d9d) #3 0x502596 in fz_set_cmm_engine (/usr/local/bin/mupdf-gl+0x502596) #4 0x525902 in fz_new_context_imp (/usr/local/bin/mupdf-gl+0x525902) #5 0x4f1609 in main (/usr/local/bin/mupdf-gl+0x4f1609) #6 0x7fa0f6588560 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x20560) SUMMARY: AddressSanitizer: heap-use-after-free (/usr/local/bin/mupdf-gl+0x63a1ea) in fz_keep_key_storable Shadow bytes around the buggy address: 0x0c267fff9790: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 fa fa 0x0c267fff97a0: fa fa fa fa fa fa fa fa 00 00 00 00 00 00 00 00 0x0c267fff97b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0c267fff97c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0c267fff97d0: 00 00 00 00 00 00 fa fa fa fa fa fa fa fa fa fa =>0x0c267fff97e0:[fd]fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd 0x0c267fff97f0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd 0x0c267fff9800: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fa fa 0x0c267fff9810: fa fa fa fa fa fa fa fa 00 00 00 00 00 00 00 00 0x0c267fff9820: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0c267fff9830: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Heap right redzone: fb Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack partial redzone: f4 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user: f7 Container overflow: fc Array cookie: ac Intra object redzone: bb ASan internal: fe Left alloca redzone: ca Right alloca redzone: cb ==10581==ABORTING Credits: Sebastian Feldmann from usd
Can someone confirm this issue?
I can confirm this issue happend in 1.12.0 as reported. However after some bisecting I discovered that starting with the commit below there wasn't any crash any more. Presumably this is because changes in the lexing affected how the PDF was parsed. Debugging at one commit prior revealed that the ASAN complains stemmed from pdf_update_free_text_annot_appearance() borrowing a colorspace reference but actually dropped it in case of an exception. But... ==================== commit fa9cd085533f68367c299e058ab3fbb7ad8a2dc6 Author: Tor Andersson <tor.andersson@artifex.com> Date: Fri Dec 1 16:07:23 2017 +0100 Fix 698785: Catch malformed numbers in PDF lexical scanner. Return error tokens when parsing numbers with trailing garbage rather than ignoring the extra characters. Also handle error tokens more gracefully in array and dictionary parsing. Treat error tokens as the 'null' keyword and continue parsing. ==================== ...it is not cool to drop others' references, so therefore we fixed this issue in the commit below. This happened after the 1.12.10 release and so is currently only fixed on git HEAD, but it will be part of the next release. ==================== commit 321ba1de287016b0036bf4a56ce774ad11763384 Author: Sebastian Rasmussen <sebras@gmail.com> Date: Tue Dec 19 23:47:47 2017 +0100 Bug 698825: Do not drop borrowed colorspaces. Previously the borrowed colorspace was dropped when updating annotation appearances, leading to use after free warnings from valgrind/ASAN. ==================== *** This bug has been marked as a duplicate of bug 698825 ***