[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#193775: marked as done (gs: Integer overflow breaks huge procedures)

Your message dated Thu, 5 Jul 2012 15:26:04 +0100
with message-id <CAPQ4b8kkvW2C65NtVY71GFdiwf5O1D7AsHZUFK7mRdR5KstUFA@mail.gmail.com>
and subject line Closing orphan/obsolete bugs (gs and gs-aladdin)
has caused the Debian Bug report #193775,
regarding gs: Integer overflow breaks huge procedures
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
193775: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=193775
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
Package: gs
Version: 7.06-1.1
Severity: normal
Tags: upstream

There's a problem with how gs handles procedure definitions. This works
fine:

(echo "1 dict dup /MaxOpStack 100000 put setuserparams {"; \
 yes 1 | head -60000 ; echo "} quit") | gs -q -dNODISPLAY -

However, this causes a very obscure rangecheck error:

(echo "1 dict dup /MaxOpStack 100000 put setuserparams {"; \
 yes 1 | head -70000 ; echo "} quit") | gs -q -dNODISPLAY -

And in fact any procedure definition of similar size will fail in the
same way.

I delved into the problem, and it seems that it's a simple overflow
problem: in iscan.c:658 gs tries to build a large array of size > 65536,
but, as seen in iref.h:370, object sizes are stored in a 16 bit integer. 
The allocation succeeds, but its size is wrong. Hence, trouble.

The Right Thing would be to support longer arrays, but failing that, at
least the size should be checked before allocation and a more sensible
diagnostic produced. I don't understand gs's internal workings well
enough to produce a patch, though.

And no, the problem does not occur only in pathological cases. Combine
autotrace, which generates very complex PS figures from bitmaps, with
html2ps, which embeds all figures into procedures, and the mess is
ready. That's how I encountered it.

-- System Information:
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux la.iki.fi 2.4.18 #1 Mon Jul 22 17:03:02 EEST 2002 i586
Locale: LANG=C, LC_CTYPE=fi_FI.ISO-8859-1

Versions of packages gs depends on:
ii  gs-common                     0.3.3      Common files for different Ghostsc
ii  libc6                         2.3.1-11   GNU C Library: Shared libraries an
ii  libgimpprint1                 4.2.5-2    Gimp-Print printer drivers - core 
ii  libpaper1                     1.1.12     Library for handling paper charact
ii  libpng12-0                    1.2.5-10   PNG library - runtime
ii  xlibs                         4.2.1-5    X Window System client libraries
ii  zlib1g                        1:1.1.4-9  compression library - runtime

-- no debconf information

--- End Message ---
--- Begin Message --- 
Hello,

Thanks for your interest in Debian, and sorry that the bugs were not
attended in due time.

gs and gs-aladdin were removed from Debian unstable long ago [1], 8+
years, at least with that package name.

Many of these reports don't have new information for years, or never
were really followed up by the people involved at the time; some even
without any activity for 10 to 15 years.  Two or three of the reports
were indeed confirmed and cloned as bugs to the more recent
"ghostscript" package.

[1] http://packages.qa.debian.org/g/gs.html
[2] http://packages.qa.debian.org/g/gs-aladdin.html

The bugs are now orphan (no maintainer assigned), so they are not
going to be noticed by anybody and dealt with, and indeed many of them
were already marked as unreproducible or contain references to files
never provided, and needed to reproduce the bug.

For all of the reasons stated, I am thus closing the bug reports now.
If somebody wants to keep them open, please reconfirm that they are
still happening and assign them to a current package, so they are not
orphan and can really be tracked.

Regards.

--- End Message ---
Reply to: