Bug 1510912 (CVE-2017-15369)

Summary:	CVE-2017-15369 mupdf: Use-after-free in the build_filter_chain function
Product:	[Other] Security Response	Reporter:	Andrej Nemec <anemec>
Component:	vulnerability	Assignee:	Red Hat Product Security <security-response-team>
Status:	CLOSED UPSTREAM	QA Contact:
Severity:	low	Docs Contact:
Priority:	low
Version:	unspecified	CC:	mjg
Target Milestone:	---	Keywords:	Security
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2019-06-08 03:30:45 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:	1500016
Bug Blocks:

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.