Bug 697015 - mutool/mupdf: use-after-free in pdf_to_num (pdf-object.c)
Summary: mutool/mupdf: use-after-free in pdf_to_num (pdf-object.c)
Status: RESOLVED FIXED
Alias: None
Product: MuPDF
Classification: Unclassified
Component: fuzzing (show other bugs)
Version: 1.9
Hardware: PC Linux
: P4 normal
Assignee: muPDF bugs
QA Contact: Bug traffic
URL:
Keywords:
: 697019 (view as bug list)
Depends on:
Blocks:
 
Reported: 2016-08-05 07:24 UTC by Agostino Sarubbo
Modified: 2016-09-22 08:46 UTC (History)
2 users (show)

See Also:
Customer:
Word Size: ---


Attachments
reproducer (3.89 KB, application/pdf)
2016-08-05 07:24 UTC, Agostino Sarubbo
Details
stacktrace (12.85 KB, text/plain)
2016-08-05 07:24 UTC, Agostino Sarubbo
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Agostino Sarubbo 2016-08-05 07:24:11 UTC
Created attachment 12809 [details]
reproducer

Hello,

there is an use-after-free in pdf_to_num triggered from a crafted file.

I'm attaching:
1) The reproducer;
2) The stacktrace provided by Address Sanitizer;
Comment 1 Agostino Sarubbo 2016-08-05 07:24:53 UTC
Created attachment 12810 [details]
stacktrace
Comment 2 Agostino Sarubbo 2016-09-21 07:01:40 UTC
The command to reproduce the issue is:
# mutool info $REPRODUCER
Comment 3 Robin Watts 2016-09-22 07:11:24 UTC
Fixed in:

commit 1e03c06456d997435019fb3526fa2d4be7dbc6ec
Author: Robin Watts <robin.watts@artifex.com>
Date:   Thu Sep 22 13:44:45 2016 +0100

    Bug 697015: Avoid object references vanishing during repair.

    A PDF repair can be triggered 'just in time', when we encounter
    a problem in the file. The idea is that this can happen without
    the enclosing code being aware of it.

    Thus the enclosing code may be holding 'borrowed' references
    (such as those returned by pdf_dict_get()) at the time when the
    repair is triggered. We are therefore at pains to ensure that
    the repair does not replace any objects that exist already, so
    that the calling code will not have these references unexpectedly
    invalidated.

    The sole exception to this is when we replace the 'Length' fields
    in stream dictionaries with the actual lengths. Bug 697015 shows
    exactly this situation causing a reference to become invalid.

    The solution implemented here is to add an 'orphan list' to the
    document, where we put these (hopefully few, small) objects. These
    orphans are kept around until the document is closed.

Thanks!
Comment 4 Sebastian Rasmussen 2016-09-22 08:46:14 UTC
*** Bug 697019 has been marked as a duplicate of this bug. ***