Opened 15 years ago
Last modified 15 years ago
#735 new defect
r.in.wms causes g.parser buffer owerflow
| Reported by: | marisn | Owned by: | |
|---|---|---|---|
| Priority: | normal | Milestone: | 6.5.0 |
| Component: | Raster | Version: | svn-develbranch6 |
| Keywords: | Cc: | ||
| CPU: | Unspecified | Platform: | Linux |
Description
I used r.in.wms to download high resolution topographical maps from local WMS service. Download part went just fine but it resulted into 287 tiles. Then r.in.wms calls r.in.gdalwarp input=/home/maris/grassdata/wms_download/topo_10k_psrs_0.png and so on 287 tile names. Such call results in buffer owerflow in g.parser:
*** buffer overflow detected ***: g.parser terminated ======= Backtrace: ========= /lib/libc.so.6(__fortify_fail+0x37)[0x7f017d0107e7] /lib/libc.so.6[0x7f017d00e5c0] /lib/libc.so.6[0x7f017d00d8b9] /lib/libc.so.6(_IO_default_xsputn+0x85)[0x7f017cf9a935] /lib/libc.so.6(_IO_vfprintf+0x35b4)[0x7f017cf6e1f4] /lib/libc.so.6(__vsprintf_chk+0x9d)[0x7f017d00d95d] /lib/libc.so.6(__sprintf_chk+0x80)[0x7f017d00d8a0] g.parser(main+0x458)[0x401668] /lib/libc.so.6(__libc_start_main+0xe6)[0x7f017cf46a26] g.parser[0x401099] ======= Memory map: ======== 00400000-00403000 r-xp 00000000 08:06 10052434 /home/maris/soft/grass6_devel/dist.x86_64-unknown-linux-gnu/bin/g.parser 00602000-00603000 r--p 00002000 08:06 10052434 /home/maris/soft/grass6_devel/dist.x86_64-unknown-linux-gnu/bin/g.parser 00603000-00604000 rw-p 00003000 08:06 10052434 /home/maris/soft/grass6_devel/dist.x86_64-unknown-linux-gnu/bin/g.parser 01169000-0118a000 rw-p 00000000 00:00 0 [heap] 7f017cb0e000-7f017cb23000 r-xp 00000000 08:02 834485 /lib64/libgcc_s.so.1 7f017cb23000-7f017cd22000 ---p 00015000 08:02 834485 /lib64/libgcc_s.so.1 7f017cd22000-7f017cd23000 r--p 00014000 08:02 834485 /lib64/libgcc_s.so.1 7f017cd23000-7f017cd24000 rw-p 00015000 08:02 834485 /lib64/libgcc_s.so.1 7f017cd24000-7f017cd26000 r-xp 00000000 08:02 294652 /lib64/libdl-2.10.1.so 7f017cd26000-7f017cf26000 ---p 00002000 08:02 294652 /lib64/libdl-2.10.1.so 7f017cf26000-7f017cf27000 r--p 00002000 08:02 294652 /lib64/libdl-2.10.1.so 7f017cf27000-7f017cf28000 rw-p 00003000 08:02 294652 /lib64/libdl-2.10.1.so 7f017cf28000-7f017d079000 r-xp 00000000 08:02 294677 /lib64/libc-2.10.1.so 7f017d079000-7f017d279000 ---p 00151000 08:02 294677 /lib64/libc-2.10.1.so 7f017d279000-7f017d27d000 r--p 00151000 08:02 294677 /lib64/libc-2.10.1.so 7f017d27d000-7f017d27e000 rw-p 00155000 08:02 294677 /lib64/libc-2.10.1.so 7f017d27e000-7f017d283000 rw-p 00000000 00:00 0 7f017d283000-7f017d305000 r-xp 00000000 08:02 294683 /lib64/libm-2.10.1.so 7f017d305000-7f017d504000 ---p 00082000 08:02 294683 /lib64/libm-2.10.1.so 7f017d504000-7f017d505000 r--p 00081000 08:02 294683 /lib64/libm-2.10.1.so 7f017d505000-7f017d506000 rw-p 00082000 08:02 294683 /lib64/libm-2.10.1.so 7f017d506000-7f017d51a000 r-xp 00000000 08:02 830733 /lib64/libz.so.1.2.3 7f017d51a000-7f017d719000 ---p 00014000 08:02 830733 /lib64/libz.so.1.2.3 7f017d719000-7f017d71a000 r--p 00013000 08:02 830733 /lib64/libz.so.1.2.3 7f017d71a000-7f017d71b000 rw-p 00014000 08:02 830733 /lib64/libz.so.1.2.3 7f017d71b000-7f017d723000 r-xp 00000000 08:06 10052200 /home/maris/soft/grass6_devel/dist.x86_64-unknown-linux-gnu/lib/libgrass_datetime.6.5.svn.so 7f017d723000-7f017d922000 ---p 00008000 08:06 10052200 /home/maris/soft/grass6_devel/dist.x86_64-unknown-linux-gnu/lib/libgrass_datetime.6.5.svn.so 7f017d922000-7f017d923000 r--p 00007000 08:06 10052200 /home/maris/soft/grass6_devel/dist.x86_64-unknown-linux-gnu/lib/libgrass_datetime.6.5.svn.so 7f017d923000-7f017d924000 rw-p 00008000 08:06 10052200 /home/maris/soft/grass6_devel/dist.x86_64-unknown-linux-gnu/lib/libgrass_datetime.6.5.svn.so 7f017d924000-7f017d978000 r-xp 00000000 08:06 10052212 /home/maris/soft/grass6_devel/dist.x86_64-unknown-linux-gnu/lib/libgrass_gis.6.5.svn.so 7f017d978000-7f017db77000 ---p 00054000 08:06 10052212 /home/maris/soft/grass6_devel/dist.x86_64-unknown-linux-gnu/lib/libgrass_gis.6.5.svn.so 7f017db77000-7f017db78000 r--p 00053000 08:06 10052212 /home/maris/soft/grass6_devel/dist.x86_64-unknown-linux-gnu/lib/libgrass_gis.6.5.svn.so 7f017db78000-7f017db7a000 rw-p 00054000 08:06 10052212 /home/maris/soft/grass6_devel/dist.x86_64-unknown-linux-gnu/lib/libgrass_gis.6.5.svn.so 7f017db7a000-7f017db81000 rw-p 00000000 00:00 0 7f017db81000-7f017db9e000 r-xp 00000000 08:02 294369 /lib64/ld-2.10.1.so 7f017dc10000-7f017dd70000 r--p 00000000 08:02 505020 /usr/lib64/locale/locale-archive 7f017dd70000-7f017dd73000 rw-p 00000000 00:00 0 7f017dd8a000-7f017dd91000 r--s 00000000 08:02 489490 /usr/lib64/gconv/gconv-modules.cache 7f017dd91000-7f017dd99000 r--p 00000000 08:06 10420339 /home/maris/soft/grass6_devel/dist.x86_64-unknown-linux-gnu/locale/lv/LC_MESSAGES/grassmods.mo 7f017dd9a000-7f017dd9d000 rw-p 00000000 00:00 0 7f017dd9d000-7f017dd9e000 r--p 0001c000 08:02 294369 /lib64/ld-2.10.1.so 7f017dd9e000-7f017dd9f000 rw-p 0001d000 08:02 294369 /lib64/ld-2.10.1.so 7fff55c2f000-7fff55c47000 rw-p 00000000 00:00 0 [stack] 7fff55cf8000-7fff55cf9000 r-xp 00000000 00:00 0 [vdso] ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall] Aborted
Attachments (1)
Change History (5)
by , 15 years ago
| Attachment: | g.parser-asprintf.patch added |
|---|
comment:1 by , 15 years ago
Replying to marisn:
I used r.in.wms to download high resolution topographical maps from local WMS service. Download part went just fine but it resulted into 287 tiles. Then r.in.wms calls r.in.gdalwarp input=/home/maris/grassdata/wms_download/topo_10k_psrs_0.png and so on 287 tile names. Such call results in buffer owerflow in g.parser:
I can fix the buffer overflow by using G_asprintf(), but some operating systems aren't going to like storing that much data in an environment variable (Linux 2.6 doesn't mind, but a limit of 4K for argv+environ is quite common).
The Python scripting library in GRASS 7 has g.parser write the information to stdout rather than using environment variables, so this isn't an issue there.
follow-up: 4 comment:2 by , 15 years ago
from grass65/scripts/r.in.wms/wms.request:
g.message "Requesting ${NUMBER_OF_TILES} tiles."
if [ "$NUMBER_OF_TILES" -gt 200 ] ; then
g.message -w "Proceed with care. This number of tiles may exceed \
the maximum command line argument length available from your \
operating system and cause an error later on in the r.in.gdalwarp \
step. In addition it may be considered abusive behavior by the \
server provider - check their terms of use."
fi
comment:3 by , 15 years ago
one trick is try to make the tiles bigger with the maxcols, maxcols so you need to get fewer tiles. Note many servers will restrict this size.
comment:4 by , 15 years ago
Replying to hamish:
from grass65/scripts/r.in.wms/wms.request:
g.message "Requesting ${NUMBER_OF_TILES} tiles."
g.message is a bad choice, as on fast machine with fast WMS server it too soon gets burried in >200 tile downloading messages.
Glynn: no idea. It's too hardcore for me. Still IMHO buffer owerflow isn't the right way how to deal with error conditions.
It would be nice if r.in.wms could calculate resulting arg length and fail if it exceeds systems capabilities (theoretical limits).
g.parser buffer overflow fix