buffer overflow in v.to.rast

[mgeeves]

The issue in bug #800 is also present in v.to.rast, long names which are > the 80 char RECORD_LEN causes a buffer overflow when writing history

sprintf -> G_snprintf swap needed

(still present in develbranch_6)

[hamish]

works for me in devbr6, and there's no difference in the v.to.rast code between that and relbr64.

r.mapcalc "map0123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789 = 103"
r.to.vect in=map0123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789 \
   out=vmap0123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789 \
   fea=area
v.to.rast in=vmap0123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789 \
   out=rvmap0123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789 \
   use=val val=105
r.info ...
 |                                                                            |
 |    v.to.rast input="vmap01234567890123456789012345678901234567890123456\   |
 |    78901234567890123456789012345678901234567890123456789" layer=1 type=\   |
 |    "point,line,area" output="rvmap0123456789012345678901234567890123456\   |
 |    789012345678901234567890123456789012345678901234567890123456789" use\   |
 |    ="val" value=105 rows=4096                                              |
 |                                                                            |
 +----------------------------------------------------------------------------+

can you provide more details about how to reproduce it? which platform?

thanks, Hamish

[mgeeves]

Hi Hamish,

Sure - this is on Ubuntu 12.04 LTS, compiled from grass-6.4.2.tar.gz

Reproducible here from two identical vectors:

v.in.ascii fs=, input=- output=p1234567890123456789012345678901234567890123456789012
0.1,51
<CTRL+D>

v.in.ascii fs=, input=- output=p12345678901234567890123456789012345678901234567890123
0.1,51
<CTRL+D>

This one works

v.to.rast input=p1234567890123456789012345678901234567890123456789012 output=r_ok use=val

This one fails

v.to.rast input=p12345678901234567890123456789012345678901234567890123 output=r_nok use=val

*** buffer overflow detected ***: v.to.rast terminated
======= Backtrace: =========
/lib/i386-linux-gnu/libc.so.6(__fortify_fail+0x45)[0xb763bdd5]
/lib/i386-linux-gnu/libc.so.6(+0xfebaa)[0xb763abaa]
/lib/i386-linux-gnu/libc.so.6(+0xfe208)[0xb763a208]
/lib/i386-linux-gnu/libc.so.6(_IO_default_xsputn+0x91)[0xb75ad461]
/lib/i386-linux-gnu/libc.so.6(_IO_vfprintf+0x53f0)[0xb7581be0]
/lib/i386-linux-gnu/libc.so.6(__vsprintf_chk+0xc9)[0xb763a2d9]
/lib/i386-linux-gnu/libc.so.6(__sprintf_chk+0x2f)[0xb763a1ef]
v.to.rast(update_hist+0xbd)[0x804b7ad]
v.to.rast(vect_to_rast+0x438)[0x804cd98]
v.to.rast(main+0x302)[0x804a432]
/lib/i386-linux-gnu/libc.so.6(__libc_start_main+0xf3)[0xb75554d3]
v.to.rast[0x804a4f9]

<SNIP>

Hopefully I've not done something daft elsewhere!

Cheers, Mike

[hamish]

I works for me on debian, 6.4.2, 6.4.3svn, and 6.5svn. Also tested 6.4.3svn on ubuntu 12.04 LTS.

Can you try building 6.4.3rc3? there were a number of overflow bugs fixed in v.to.rast since 6.4.2 to do with labels, which are now fixed. it could have been something related to that.

Hopefully I've not done something daft elsewhere!

a buffer overflow is pretty much always the programmer's fault.

Hamish

[mgeeves]

Hi Hamish,

Odd, I'm still seeing the same problem in grass-6.4.3RC3. Re being daft I mostly meant having old bits from previous SVN builds conflicting. To rule that out I've tried building another vm with vmbuilder (defaults apart from adding in a few bits like the sshd and deb-src repos), then an

apt-get build-dep grass

and building from grass-6.4.3RC3.tar.gz with:

./configure --with-proj-share=/usr/share/proj --with-tcltk-includes=/usr/include/tcl8.5

Installing using checkinstall with defaults

Same result, buffer overrun! Note the raster is actually generated and displays ok, it just displays the overflow error and doesn't record to hist

After changing the code in support.c to use G_snprintf, it doesn't error for me any more..

Cheers, Mike

[hamish]

ok, I could reproduce it in a package build after making the name a bit longer, I guess the unoptimized 'gcc -g' in my source build was zeroing all memory or so, shrug.

fixed in devbr6 in r56254. please everyone test so it can be applied to 6.4svn in time for the release.

thanks, Hamish

[mgeeves]

Looking better for me, thanks!

[hamish]

fix backported to relbr64 in r56744.