Created attachment 19029 [details] PoC for a UAF bug Hi, I found a use after free vulnerability in mupdf, as demonstrated by mutool on the latest commit 6566de7, via a crafted pdf file. To reproduce: mutool draw -o /dev/null -R 832 -h 22 $PoC Valgrind says: ~~~ ==25732== Invalid read of size 8 ==25732== at 0x497294: fz_drop_band_writer (output.c:717) ==25732== by 0x405BB0: dodrawpage (mudraw.c:907) ==25732== by 0x406956: drawpage (mudraw.c:1165) ==25732== by 0x406A0F: drawrange (mudraw.c:1181) ==25732== by 0x408AFC: mudraw_main (mudraw.c:1914) ==25732== by 0x402BAB: main (mutool.c:130) ==25732== Address 0x587eb40 is 0 bytes inside a block of size 240 free'd ==25732== at 0x4C2EDEB: free (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==25732== by 0x487DC4: fz_free_default (memory.c:171) ==25732== by 0x487CF5: fz_free (memory.c:142) ==25732== by 0x4972DC: fz_drop_band_writer (output.c:720) ==25732== by 0x405BB0: dodrawpage (mudraw.c:907) ==25732== by 0x406956: drawpage (mudraw.c:1165) ==25732== by 0x406A0F: drawrange (mudraw.c:1181) ==25732== by 0x408AFC: mudraw_main (mudraw.c:1914) ==25732== by 0x402BAB: main (mutool.c:130) ==25732== Block was alloc'd at ==25732== at 0x4C2DB8F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==25732== by 0x487D7D: fz_malloc_default (memory.c:159) ==25732== by 0x4878B7: do_scavenging_malloc (memory.c:30) ==25732== by 0x487AFE: fz_calloc (memory.c:90) ==25732== by 0x497072: fz_new_band_writer_of_size (output.c:640) ==25732== by 0x48F822: fz_new_png_band_writer (output-png.c:329) ==25732== by 0x4055AF: dodrawpage (mudraw.c:823) ==25732== by 0x406956: drawpage (mudraw.c:1165) ==25732== by 0x406A0F: drawrange (mudraw.c:1181) ==25732== by 0x408AFC: mudraw_main (mudraw.c:1914) ==25732== by 0x402BAB: main (mutool.c:130) ==17292== Invalid read of size 8 ==17292== at 0x48F7D1: png_drop_band_writer (output-png.c:323) ==17292== by 0x4972B2: fz_drop_band_writer (output.c:718) ==17292== by 0x405BB0: dodrawpage (mudraw.c:907) ==17292== by 0x406956: drawpage (mudraw.c:1165) ==17292== by 0x406A0F: drawrange (mudraw.c:1181) ==17292== by 0x408AFC: mudraw_main (mudraw.c:1914) ==17292== by 0x402BAB: main (mutool.c:130) ==17292== Address 0x587eba0 is 96 bytes inside a block of size 240 free'd ==17292== at 0x4C2EDEB: free (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==17292== by 0x487DC4: fz_free_default (memory.c:171) ==17292== by 0x487CF5: fz_free (memory.c:142) ==17292== by 0x4972DC: fz_drop_band_writer (output.c:720) ==17292== by 0x405BB0: dodrawpage (mudraw.c:907) ==17292== by 0x406956: drawpage (mudraw.c:1165) ==17292== by 0x406A0F: drawrange (mudraw.c:1181) ==17292== by 0x408AFC: mudraw_main (mudraw.c:1914) ==17292== by 0x402BAB: main (mutool.c:130) ==17292== Block was alloc'd at ==17292== at 0x4C2DB8F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==17292== by 0x487D7D: fz_malloc_default (memory.c:159) ==17292== by 0x4878B7: do_scavenging_malloc (memory.c:30) ==17292== by 0x487AFE: fz_calloc (memory.c:90) ==17292== by 0x497072: fz_new_band_writer_of_size (output.c:640) ==17292== by 0x48F822: fz_new_png_band_writer (output-png.c:329) ==17292== by 0x4055AF: dodrawpage (mudraw.c:823) ==17292== by 0x406956: drawpage (mudraw.c:1165) ==17292== by 0x406A0F: drawrange (mudraw.c:1181) ==17292== by 0x408AFC: mudraw_main (mudraw.c:1914) ==17292== by 0x402BAB: main (mutool.c:130) ~~~ ASAN aslo detects an invalid read of size 8 due to a heap use after free, but I cannot produce a detailed bug stack trace using `make sanitize`. Thanks, Manh Dung
commit 96751b25462f83d6e16a9afaf8980b0c3f979c8b Author: theshoals <theshoals@users.noreply.github.com> Date: Mon May 4 03:33:40 2020 -0400 Bug 702253: Avoid a use-after-free in fz_drop_band_writer A use-after-free would occur when a valid page was followed by a page with invalid pixmap dimensions, causing bander -- a static -- to point to previously freed memory instead of a new band_writer.