Created attachment 14334 [details] PoC to trigger use-after-free (mutool) After some fuzz testing I found a crashing test case. Git Head: 9c83cbb80b08dadb575c62790e4084f04307a2e5 Command: mutool info mupdf_uaf_fz_drop_imp ASAN: ==18140==ERROR: AddressSanitizer: heap-use-after-free on address 0x60700000ded0 at pc 0x00000053b7bf bp 0x7ffed6110630 sp 0x7ffed6110620 READ of size 4 at 0x60700000ded0 thread T0 #0 0x53b7be in fz_drop_imp include/mupdf/fitz/context.h:659 #1 0x53b7be in fz_drop_stream source/fitz/stream-open.c:59 #2 0x5b21c1 in build_filter_chain source/pdf/pdf-stream.c:265 #3 0x5b298e in pdf_open_filter source/pdf/pdf-stream.c:346 #4 0x5b2af5 in pdf_open_image_stream source/pdf/pdf-stream.c:439 #5 0x699c66 in pdf_repair_obj_stm source/pdf/pdf-repair.c:220 #6 0x69d09c in pdf_repair_obj_stms source/pdf/pdf-repair.c:708 #7 0x5d9fbb in pdf_init_document source/pdf/pdf-xref.c:1397 #8 0x5daa8c in pdf_open_document source/pdf/pdf-xref.c:2278 #9 0x43e8fc in pdfinfo_info source/tools/pdfinfo.c:976 #10 0x43f193 in pdfinfo_main source/tools/pdfinfo.c:1046 #11 0x40e3e8 in main source/tools/mutool.c:125 #12 0x7f5b06f1582f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f) #13 0x410b68 in _start (XYZ/Desktop/mupdf/build/debug/mutool+0x410b68) 0x60700000ded0 is located 0 bytes inside of 80-byte region [0x60700000ded0,0x60700000df20) freed by thread T0 here: #0 0x7f5b0787d2ca in __interceptor_free (/usr/lib/x86_64-linux-gnu/libasan.so.2+0x982ca) #1 0x4efb19 in fz_free source/fitz/memory.c:194 previously allocated by thread T0 here: #0 0x7f5b0787d602 in malloc (/usr/lib/x86_64-linux-gnu/libasan.so.2+0x98602) #1 0x4f0158 in do_scavenging_malloc source/fitz/memory.c:21 SUMMARY: AddressSanitizer: heap-use-after-free include/mupdf/fitz/context.h:659 fz_drop_imp Shadow bytes around the buggy address: 0x0c0e7fff9b80: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c0e7fff9b90: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c0e7fff9ba0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c0e7fff9bb0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c0e7fff9bc0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa =>0x0c0e7fff9bd0: fa fa fa fa fa fa fa fa fa fa[fd]fd fd fd fd fd 0x0c0e7fff9be0: fd fd fd fd fa fa fa fa 00 00 00 00 00 00 00 00 0x0c0e7fff9bf0: 00 00 fa fa fa fa 00 00 00 00 00 00 00 00 00 00 0x0c0e7fff9c00: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c0e7fff9c10: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c0e7fff9c20: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 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 ==18140==ABORTING
I could only reproduce this issue when running make build=sanitize if I also added -O2 into the mix. To make it easier I committed 32a7ebd389cbd2df02034400c7536ab8330984ca which adds a build=sanitize-release which allows for easier testing of optimized builds using ASAN in the future.
Commit c2663e51238ec8256da7fc61ad580db891d9fe9a fixes this bug which originated from forgetting to fz_var() a variable in commit 2707fa9e8e6d17d794330e719dec1b08161fb045 I can no longer reproduce the issue.