Bug 691044 - Vulnerability report : Ghostscript Heap Overflow
Summary: Vulnerability report : Ghostscript Heap Overflow
Alias: None
Product: Ghostscript
Classification: Unclassified
Component: General (show other bugs)
Version: master
Hardware: PC Linux
: P4 normal
Assignee: Ken Sharp
Depends on:
Reported: 2010-01-04 22:18 UTC by Marcos H. Woehrmann
Modified: 2021-09-11 12:56 UTC (History)
3 users (show)

See Also:
Word Size: ---


Note You need to log in before you can comment on or make changes to this bug.
Description Marcos H. Woehrmann 2010-01-04 22:18:25 UTC
A user has found a heap overflow in Ghostscript.

The issue will be described in a private attachment.
Comment 1 Marcos H. Woehrmann 2010-01-04 22:18:42 UTC
Created attachment 5847 [details]
Comment 2 Marcos H. Woehrmann 2010-01-04 22:19:14 UTC
Created attachment 5848 [details]
Comment 3 Ray Johnston 2010-01-07 10:18:19 UTC
May be a font issue
Comment 4 Ken Sharp 2010-01-07 11:38:44 UTC
Looks like it is a font issue. Also, like the last one, it gives an error on
Windows instead of a crash. The previous issue was partially due to probably
random data because of broken compressed stream, and influenced by optimisations
in gcc (debug build didn't crash).

I'll need to run it on Linux tomorrow to see what's happening, and probably
build an optimised executable with debug info.
Comment 5 Marcos H. Woehrmann 2010-01-07 12:04:53 UTC
Created attachment 5856 [details]

The original user has sent some further analysis.

He's is also wondering if this issue or the previous one (Bug #691043) were
significant enough to qualify as bountiable.  Ray?
Comment 6 Ken Sharp 2010-01-09 03:05:16 UTC
Using ddd, the file doesn't provoke a SEGV, in fact on Fedora I'm unable to
reproduce a crash at all. Given the fact that this 'probably' depends on the
content of uninitialised memory that's not entirely surprising.

I have read update.txt but I'm not completely happy about the proposed fix, I'll
do some debugging then some desk checking and think about it.
Comment 7 Ken Sharp 2010-01-11 04:11:08 UTC
OK, this is hopefully fixed by revision 10602:


As noted in the log, I've chosen to simply return when the argument to MINDEX is
0. This is because it seems to be legal, if daft, and we know from experience
that just because its silly doesn't mean that producers won't create fonts like

Unfortunately I have never actually managed to reproduce this problem, so I
can't be certain this patch fixes it. It would be best if someone who could
previously reproduce the problem woucl check this.