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 ---
- To: Debian Bug Tracking System <submit@bugs.debian.org>
- Subject: gs: Integer overflow breaks huge procedures
- From: Lauri Alanko <la@iki.fi>
- Date: Sun, 18 May 2003 20:25:13 +0300
- Message-id: <E19HRuL-00037Y-00@la.iki.fi>
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 ---
- To: 612010-done@bugs.debian.org
- Subject: Re: gs: Integer overflow breaks huge procedures
- From: Steven Robbins <steve@sumost.ca>
- Date: Thu, 21 Dec 2023 23:05:00 -0600
- Message-id: <7584204.DvuYhMxLoT@riemann>
- In-reply-to: <E19HRuL-00037Y-00@la.iki.fi>
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 ---