[gs-bugs] [Bug 690330] MuPDF crash (mupdf/pdf_function.c:1260)

bugs.ghostscript.com-bugzilla-daemon at ghostscript.com bugs.ghostscript.com-bugzilla-daemon at ghostscript.com
Thu Mar 26 17:30:22 PDT 2009


http://bugs.ghostscript.com/show_bug.cgi?id=690330





------- Additional Comments From kkowalczyk at gmail.com  2009-03-26 17:30 -------
I have fix at
http://github.com/kjk/mupdf/commit/fb6732b808d3e7846bfcd92fdfb082c0d2491548

Also attached for good measure.

$ git diff
diff --git a/mupdf/pdf_function.c b/mupdf/pdf_function.c
index 42c6cd4..356a78f 100644
--- a/mupdf/pdf_function.c
+++ b/mupdf/pdf_function.c
@@ -1250,9 +1250,8 @@ loadstitchingfunc(pdf_function *func, pdf_xref *xref,
fz_obj *dict)
                        return fz_rethrow(error, "cannot resolve /Functions");

                k = fz_arraylen(obj);
-               func->u.st.k = k;

-               pdf_logrsrc("k %d\n", func->u.st.k);
+               pdf_logrsrc("k %d\n", k);

                if (k >= MAXK)
                {
@@ -1260,6 +1259,7 @@ loadstitchingfunc(pdf_function *func, pdf_xref *xref,
fz_obj *dict)
                        return fz_throw("assert: /K too big (%d)", k);
                }

+               func->u.st.k = k;
                for (i = 0; i < k; ++i)
                {
                        sub = fz_arrayget(obj, i);


The problem is that we set func->u.st.k even if we don't have those functions
(in error case). This will cause us to try to drop null function objects, which
crashes:

Program received signal SIGSEGV, Segmentation fault.
pdf_dropfunction (func=0x0) at mupdf/pdf_function.c:1416
1416            if (--func->refs == 0)
(gdb) bt
#0  pdf_dropfunction (func=0x0) at mupdf/pdf_function.c:1416
#1  0x0043db0c in pdf_loadfunction (funcp=0x22c4bc, xref=0xca6f38, ref=0xd38858)
    at mupdf/pdf_function.c:1427
#2  0x0044b558 in pdf_loadshadefunction (shade=0xd4fb98, xref=0xca6f38,
shading=0xd31cd0, t0=0,
    t1=1) at mupdf/pdf_shade.c:11
#3  0x0044dc0c in pdf_loadtype3shade (shade=0xd4fb98, xref=0xca6f38,
shading=0xd31cd0,
    ref=0xcbbec0) at mupdf/pdf_shade1.c:355
#4  0x0044bd77 in loadshadedict (shadep=0x22c6b8, xref=0xca6f38, dict=0xd31cd0,
ref=0xcbbec0,
    matrix={a = 1, b = 0, c = 0, d = 1, e = 0, f = 0}) at mupdf/pdf_shade.c:225
#5  0x0044c08a in pdf_loadshade (shadep=0x22c6b8, xref=0xca6f38, dict=0xd31cd0,
ref=0xcbbec0)
    at mupdf/pdf_shade.c:319
#6  0x0044b139 in pdf_loadresources (rdbp=0x22c750, xref=0xca6f38, orig=0xcbb668)
    at mupdf/pdf_resources.c:129
#7  0x00447043 in pdf_loadpage (pagep=0x8e390c, xref=0xca6f38, dict=0xcbb638)
    at mupdf/pdf_page.c:225
#8  0x004550ff in drawloadpage (pagenum=4, loadtimes=0x22cbf0) at apps/pdfdraw.c:155
#9  0x00455287 in drawpnm (pagenum=4, loadtimes=0x22cbf0, drawtimes=0x22cbd0) at
apps/pdfdraw.c:216
#10 0x00455d22 in drawpages (pagelist=0x0) at apps/pdfdraw.c:402
#11 0x00456027 in main (argc=3, argv=0xca2520) at apps/pdfdraw.c:481

Alternatively, pdf_dropfunction() could just ignore null func.

Also, MAXK = 32 (in pdf_function.c) seems a bit restrictive. I've seen a PDF
with k being 255, so increasing this to at least 256 would be nice.
Alternatively, if size of objects is an issue, the code could dynamically
allocate arrays that depend on MAX, instead of putting stuff inline.




------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.



More information about the gs-bugs mailing list