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

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



Your message dated Thu, 21 Dec 2023 23:05:00 -0600
with message-id <7584204.DvuYhMxLoT@riemann>
and subject line Re: gs: Integer overflow breaks huge procedures
has caused the Debian Bug report #612010,
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.)


-- 
612010: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=612010
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 ---
On Sun, 18 May 2003 20:25:13 +0300 Lauri Alanko <la@iki.fi> wrote:
> Package: gs
> Version: 7.06-1.1
> Severity: normal
> Tags: upstream

This was fixed upstream in 2012. 
I tested the reported repro and got no errors.

-Steve

> 
> 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
> 
> 
> 

Attachment: signature.asc
Description: This is a digitally signed message part.


--- End Message ---

Reply to: