Bug 689975

Summary:	double free in file_close_disable
Product:	Ghostscript	Reporter:	Ralph Giles <ralph.giles>
Component:	General	Assignee:	Alex Cherepanov <alex>
Status:	RESOLVED FIXED
Severity:	normal
Priority:	P3
Version:	8.62
Hardware:	PC
OS:	Linux
Customer:		Word Size:	---

Description Ralph Giles 2008-07-17 12:02:49 UTC

User reports a double-free viewing a PDF with gv.

The following command line also shows the problem:

$ gs -sDEVICE=x11 -dTextAlphaBits=2 -dGraphicsAlphaBits=2 -dAlignToPixels=0
-dMaxBitmap=10000000 -dNOPLATFONTS -dNOPAUSE -dQUIET -dSAFER -dFIXEDMEDIA - <
X0510_01.pdf

Error: /invalidfileaccess in findresource
[...stack dump...]
Current allocation mode is global
GPL Ghostscript 8.62: Unrecoverable error, exit code 1

*** glibc detected *** gs: double free or corruption (!prev): 0x08924658 ***
======= Backtrace: =========
/lib/libc.so.6[0xb7aaea20]
/lib/libc.so.6(cfree+0x89)[0xb7ab0709]
/lib/libc.so.6(fclose+0x152)[0xb7a9eef2]
gs[0x81157c3]
gs(file_close_disable+0x13)[0x80f6173]
gs(file_close_file+0x1a)[0x8115dca]
gs(sclose+0x1b)[0x80f677b]
gs(gs_gc_reclaim+0xbd3)[0x8111703]
gs[0x8186d6b]
gs[0x80ef350]
gs(interp_reclaim+0x43)[0x80eb133]
gs(gs_main_finit+0x100)[0x80e2b40]
gs(main+0xee)[0x80884de]
/lib/libc.so.6(__libc_start_main+0xdc)[0xb7a5efdc]
gs[0x8088361]

Comment 1 Ralph Giles 2008-07-17 12:05:43 UTC

Created attachment 4229 [details]
X0510_01.pdf

Comment 2 Ralph Giles 2008-07-17 12:22:29 UTC

I've reproduced with trunk and the following minimal command line:

$ debugobj/gs -dSAFER - < X0510_01.pdf

The file uses Japanese fonts, and so the following must be added to lib/cidfmap:

/Kochi-Gothic                   << /FileType /TrueType /Path
(/usr/share/fonts/truetype/kochi/kochi-gothic-subst.ttf) /CSI [(Japan1) 6] >> ;
/Kochi-Gothic-Regular           /Kochi-Gothic ;
/Kochi-Gothic-JaH               << /FileType /TrueType /Path
(/usr/share/fonts/truetype/kochi/kochi-gothic-subst.ttf) /CSI [(Japan2) 0] >> ;
/Kochi-Gothic-Regular-JaH       /Kochi-Gothic-JaH ;
/Kochi-Mincho                   << /FileType /TrueType /Path
(/usr/share/fonts/truetype/kochi/kochi-mincho-subst.ttf) /CSI [(Japan1) 6] >> ;
/Kochi-Mincho-Regular           /Kochi-Mincho ;
/Kochi-Mincho-JaH               << /FileType /TrueType /Path
(/usr/share/fonts/truetype/kochi/kochi-mincho-subst.ttf) /CSI [(Japan2) 0] >> ;
/Kochi-Mincho-Regular-JaH       /Kochi-Mincho-JaH ;
/Ryumin-Light                   /Kochi-Mincho ;
/GothicBBB-Medium               /Kochi-Gothic ;
/Adobe-Japan1                   /Kochi-Gothic ;
/Adobe-Japan2                   /Kochi-Gothic-JaH ;

These paths are specific to Ubuntu Linux. The user had different ones from the
gentoo build.

Both -dSAFER and feeding the file from stdin are necessary to reproduce the
double free. The /invalidfileaccess is because the fonts referenced from cidfmap
are not on the permitted read list. If they're added (for example with
-I/usr/share/fonts/truetype/kochi in the example above) the double free is not
reported. In this case the document still doesn't render past the first page,
complaining:

Loading a TT font from /usr/share/fonts/truetype/kochi/kochi-gothic-subst.ttf to
emulate a CID font Kochi-Gothic ... Done.
Error: /invalidfont in --.buildcidfont--

So there may be other issues with this file, or with the cidfmap used.

The file appears to have some kind of javascript DRM, and displays as blank in
evince and Apple Preview. Adobe Reader asks if the document can access itself
through a url and when blocked also shows the document as blank. However the
content is visible briefly when scrolling.

Comment 3 Ray Johnston 2008-07-17 12:48:03 UTC

Double free can cause stability problems.

We have many customers using Asian CID fonts, but I don't know if they are
having 'PermitFileReading' problems (most don't bother with -dSAFER).

Comment 4 Alex Cherepanov 2008-12-28 08:09:14 UTC

Use a proper destructor to free a file stream when access to the file is not
permitted in the safe mode, not just close the file and drop the rest of the
file structure.

The following patch is committed as a rev. 9307.
http://ghostscript.com/pipermail/gs-cvs/2008-December/008885.html

Our standard regression testing doesn't cover the safe mode.
Testing under Valgrind shows that double fclose() (and double free())
no longer occurs.