#26 fig2dev: Invalid memory read crash while running with '-L pdf' option

[Roland Rosenfeld]

Here's another issue reported against the Debian package (see: https://bugs.debian.org/906743):

--------- schnipp ----------
Running the attached test input with fig2dev with '-L pdf' option raises a
segmentation fault error, while attempting to read an invalid memory
address. Judging from the stack trace, this bug seems similar to previous
bug #890016, but this test input also crashes the latest upstream version
(3.2.7a) of fig2dev, where #890016 is supposed to be fixed. The bug fix
could have been incomplete, or this may be a distinct bug.

Below is the gdb log. I used latest upstream version 3.2.7a here, but I
confirmed that current stable version 3.2.6a is also affected.

jason@debian-amd64-stretch:~/report/source-latest/fig2dev$ gdb
./fig2dev-3.2.7a-llvm/fig2dev/fig2dev -q
Reading symbols from ./fig2dev-3.2.7a-llvm/fig2dev/fig2dev...done.
(gdb) run -L pdf poc-invalid
Starting program:
/home/jason/report/source-latest/fig2dev/fig2dev-3.2.7a-llvm/fig2dev/fig2dev
-L pdf poc-invalid
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
incomplete line object

Program received signal SIGSEGV, Segmentation fault.
free_linestorage (l=<optimized out="">) at free.c:152
152 free.c: No such file or directory.
(gdb) x/i $rip
=> 0x4095c6 <free_linestorage+70>: mov 0x8(%rax),%rdi
(gdb) info reg rax
rax 0x3333333333333333 3689348814741910323
(gdb) where
#0 free_linestorage (l=<optimized out="">) at free.c:152
#1 0x0000000000409bb0 in read_lineobject (fp=<optimized out="">) at
read1_3.c:378
#2 0x0000000000409927 in read_1_3_objects (fp=<optimized out="">,
obj=<optimized out="">) at read1_3.c:100
#3 0x000000000040ab95 in readfp_fig (fp=0x6a3f20, obj=0x7fffffffe3d0) at
read.c:174
#4 0x0000000000408bac in main (argc=<optimized out="">, argv=<optimized out="">)
at fig2dev.c:424</optimized></optimized></optimized></optimized></optimized></optimized></free_linestorage+70></optimized>

For your information, running with Address Sanitizer failed to provide any
further useful information.

--------- schnipp ----------

I can reproduce this issue on my system with the following backtrace:

#0 free_linestorage (l=0x5643c1554150) at free.c:152
p = <optimized out="">
q = <optimized out="">
#1 0x00005643c0854720 in read_lineobject (fp=fp@entry=0x5643c1553f20) at read1_3.c:405
l = <optimized out="">
p = 0x5643c15541d0
q = <optimized out="">
f = 2
b = 2
h = 2
w = 2
n = <optimized out="">
t = 1
x = 2
y = 0
#2 0x00005643c08554e8 in read_1_3_objects (fp=fp@entry=0x5643c1553f20, obj=obj@entry=0x7ffc7fba7760) at read1_3.c:100
e = <optimized out="">
le = 0x0
l = <optimized out="">
ll = 0x0
t = <optimized out="">
lt = 0x0
s = <optimized out="">
ls = 0x0
a = <optimized out="">
la = 0x0
c = <optimized out="">
lc = 0x0
n = <optimized out="">
object = 2
pixperinch = 2
canvaswid = -1
canvasht = 2
coord_sys = 2
#3 0x00005643c08583ca in readfp_fig (fp=0x5643c1553f20, obj=0x7ffc7fba7760) at read.c:174
c = 10 '\n'
status = <optimized out="">
#4 0x00005643c084de14 in main (argc=<optimized out="">, argv=0x7ffc7fba78c8) at fig2dev.c:424
objects = {nwcorner = {x = 2, y = 2}, secorner = {x = 0, y = 0}, lines = 0x0, ellipses = 0x0, splines = 0x0, texts = 0x0, arcs = 0x0, compounds = 0x0, comments = 0x0,
next = 0x0}
status = <optimized out=""></optimized></optimized></optimized></optimized></optimized></optimized></optimized></optimized></optimized></optimized></optimized></optimized></optimized></optimized></optimized>

Greetings
Roland

[tkl]

Hi Roland,

this issue is now fixed in the development version, see commit e9d1fd. The reason for the bug was, that a member of the line object struct was not initalized when reading in fig files version 1.3. As I can see, input sanitizing is only performed on fig files > 1.3. Hence, this bug might point to more issues still being present in the code: First, whether all objects are properly initialized for old fig files, secondly, whether invalid objects can be read in when using format 1.3.

Yours,
Thomas

[tkl]

Fixed with release 3.2.7b.