Bug 1510912 (CVE-2017-15369) - CVE-2017-15369 mupdf: Use-after-free in the build_filter_chain function
Summary: CVE-2017-15369 mupdf: Use-after-free in the build_filter_chain function
Keywords:
Status: CLOSED UPSTREAM
Alias: CVE-2017-15369
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
low
low
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
URL:
Whiteboard:
Depends On: 1500016
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-11-08 12:46 UTC by Andrej Nemec
Modified: 2019-09-29 14:25 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-06-08 03:30:45 UTC
Embargoed:


Attachments (Terms of Use)

Description Andrej Nemec 2017-11-08 12:46:28 UTC
The build_filter_chain function in pdf/pdf-stream.c in Artifex MuPDF before 2017-09-25 mishandles a certain case where a variable may reside in a register, which allows remote attackers to cause a denial of service (Fitz fz_drop_imp use-after-free and application crash) or possibly have unspecified other impact via a crafted PDF document.

Upstream issue:

https://bugs.ghostscript.com/show_bug.cgi?id=698592

Upstream patch:

http://git.ghostscript.com/?p=mupdf.git;h=c2663e51238ec8256da7fc61ad580db891d9fe9a

Comment 1 Andrej Nemec 2017-11-08 12:46:53 UTC
Created mupdf tracking bugs for this issue:

Affects: fedora-all [bug 1500016]

Comment 2 Michael J Gruber 2017-11-11 20:09:59 UTC
Fix is in rawhide
Release update waiting for the jpeg2dec update from bug 1456730 to land.

BTW: Those automatically created dependency chains in bz seem completely backwards - would I have to work on a bug against component "vulnerability" (as per the comment 1500016) when, on the other hand, that bug block this one? This is a nightmare, and gives wrong resolutions when an update fixes one specific bug and thus has that number in its update description.

In short: the tracking bug should depend on the bugs that it tracks, not block them! The individual bugs should be filed against the component "mupdf", not against "vulnerability". I have no business in that component.

Comment 3 Andrej Nemec 2017-11-13 14:12:42 UTC
(In reply to Michael J Gruber from comment #2)
> Fix is in rawhide
> Release update waiting for the jpeg2dec update from bug 1456730 to land.
> 
> BTW: Those automatically created dependency chains in bz seem completely
> backwards - would I have to work on a bug against component "vulnerability"
> (as per the comment 1500016) when, on the other hand, that bug block this
> one? This is a nightmare, and gives wrong resolutions when an update fixes
> one specific bug and thus has that number in its update description.
> 
> In short: the tracking bug should depend on the bugs that it tracks, not
> block them! The individual bugs should be filed against the component
> "mupdf", not against "vulnerability". I have no business in that component.

Thanks!

As for the bugs, you should not be touching this one at all. This vulnerability bug is used by the Product Security Team to track the vulnerability itself. Fixing of the issue in Fedora should be done in the tracking bug 1500016.

The thinking here is that the tracking bug blocks the vulnerability bug resolution and the vulnerability bug depends on the tracking bug :)

Comment 4 Product Security DevOps Team 2019-06-08 03:30:45 UTC
This CVE Bugzilla entry is for community support informational purposes only as it does not affect a package in a commercially supported Red Hat product. Refer to the dependent bugs for status of those individual community products.


Note You need to log in before you can comment on or make changes to this bug.