[tex-k] (fwd) Dvips has a string allocation bug in papersize handling (patch included)

[Hilmar Preusse]

Hi,

This is said to be the bug-report address of dvips. We've got two
bugs in the Debian Bug Tracking system, which seems to be the same
and still present in latest dvips.
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=147976
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=196113

Comments, hints, remarks?

----- Forwarded message from Kevin Buhr <buhr at telus.net> -----

From: Kevin Buhr <buhr at telus.net>
To: submit at bugs.debian.org
Subject: Dvips has a string allocation bug in papersize handling (patch included)
Date: 23 May 2002 18:13:06 -0700
Message-ID: <87g00ibb6l.fsf at saurus.asaurus.invalid>

Package: tetex-bin
Version: 1.0.7+20011202-7

Dvips (at least in Woody) has a string allocation bug that will
cause it to produce bad PostScript in some circumstances.  A patch is
included below.

The paper size specifications in the Dvips configuration file may
include "@+" lines giving PostScript code to be sent to the printer
for that paper size.  Dvips fails to correctly null-terminate this
code string when there are no "@+" lines associated with a particular
specification.  For example, given the specifications:

        @ letterSize 8.5in 11in

        @ A4size 210mm 297mm
        @+ %%PaperSize: A4

Dvips will allocate a single byte for the empty PostScript code for
the "letterSize" specification but will fail to null-terminate the
string.

In the event this location was not already null, Dvips will write
the next string in the string pool, in this case "A4size", into the
PostScript file, like so:

        %%BeginSetup
        %%Feature: *Resolution 600dpi
        TeXDict begin
>>>     A4size

        %%EndSetup

It is a peculiarity of the Dvips code that the first character of the
PostScript code is ignored, which is why the bad non-null byte,
whatever it is, is not actually output.

Also, note that the string pool is *usually* mostly null when Dvips
gets underway, so in practice the bug is rarely observed.  I've run
into it only a handful of times, and it was highly sensitive to the
exact size of my set of environment strings, for example.

The following patch fixes the problem.

Kevin Buhr <buhr at telus.net>

                        *       *       *

diff -ru tetex-bin-1.0.7+20011202~/texk/dvipsk/resident.c tetex-bin-1.0.7+20011202/texk/dvipsk/resident.c
--- tetex-bin-1.0.7+20011202~/texk/dvipsk/resident.c    Thu Nov  1 11:27:45 2001
+++ tetex-bin-1.0.7+20011202/texk/dvipsk/resident.c     Thu May 23 17:28:19 2002
@@ -496,7 +496,7 @@
             handlepapersize(p, &hsiz, &vsiz) ;
             ps->xsize = hsiz ;
             ps->ysize = vsiz ;
-            ps->specdat = nextstring++ ;
+            *(ps->specdat = nextstring++) = '\0' ;
             canaddtopaper = 1 ;
          }
          break ;
----- End forwarded message -----

Regards,
  Hilmar
-- 
sigmentation fault