viking icon indicating copy to clipboard operation
viking copied to clipboard

buffer overflow detected after commit 8a439f317d60281cdb3f6dab57dd51b7315a90de

Open inode64 opened this issue 6 years ago • 10 comments

When I open anyone file .gpx show this error

*** buffer overflow detected ***: /usr/bin/viking terminated

Thread 1 "viking" received signal SIGABRT, Aborted. 0x00007ffff30e5b98 in raise () from /lib64/libc.so.6 (gdb) bt #0 0x00007ffff30e5b98 in raise () from /lib64/libc.so.6 #1 0x00007ffff30e768e in abort () from /lib64/libc.so.6 #2 0x00007ffff312c0b7 in ?? () from /lib64/libc.so.6 #3 0x00007ffff31c635e in ?? () from /lib64/libc.so.6 #4 0x00007ffff31c63a1 in __fortify_fail () from /lib64/libc.so.6 #5 0x00007ffff31c39e0 in __chk_fail () from /lib64/libc.so.6 #6 0x00007ffff31c419b in __realpath_chk () from /lib64/libc.so.6 #7 0x00005555555d75b4 in realpath (__resolved=0x7fffffffbf50 "", __name=0x555555de72b0 "/home/fran/Descargas/rutas/bexti.gpx") at /usr/include/bits/stdlib.h:45 #8 file_realpath (real=0x7fffffffbf50 "", path=0x555555de72b0 "/home/fran/Descargas/rutas/bexti.gpx") at fileutils.c:55 #9 file_realpath_dup (path=0x555555de72b0 "/home/fran/Descargas/rutas/bexti.gpx", path@entry=0x555555bfee80 "\226") at fileutils.c:70 #10 0x00005555555d65e5 in a_file_load (top=0x7fffffff, vp=vp@entry=0x555555a6e0a0, vtl=vtl@entry=0x0, filename_or_uri=, filename_or_uri@entry=0x555555de72b0 "/home/fran/Descargas/rutas/bexti.gpx") at file.c:682 #11 0x0000555555613d28 in vik_window_open_file (vw=0x555555a6a090, filename=0x555555de72b0 "/home/fran/Descargas/rutas/bexti.gpx", change_filename=1) at vikwindow.c:3109 #12 0x00005555556149df in load_file (a=, vw=0x555555a6a090) at vikwindow.c:3296 #13 0x00007ffff6775395 in g_closure_invoke () from /usr/lib64/libgobject-2.0.so.0 #14 0x00007ffff678894b in ?? () from /usr/lib64/libgobject-2.0.so.0 #15 0x00007ffff679113c in g_signal_emit_valist () from /usr/lib64/libgobject-2.0.so.0 #16 0x00007ffff6791acf in g_signal_emit () from /usr/lib64/libgobject-2.0.so.0 #17 0x00007ffff7813b88 in ?? () from /usr/lib64/libgtk-x11-2.0.so.0 #18 0x00007ffff79a9b29 in ?? () from /usr/lib64/libgtk-x11-2.0.so.0 #19 0x00007ffff6775395 in g_closure_invoke () from /usr/lib64/libgobject-2.0.so.0 #20 0x00007ffff678894b in ?? () from /usr/lib64/libgobject-2.0.so.0 #21 0x00007ffff679113c in g_signal_emit_valist () from /usr/lib64/libgobject-2.0.so.0 #22 0x00007ffff6791acf in g_signal_emit () from /usr/lib64/libgobject-2.0.so.0 #23 0x00007ffff782dc2d in ?? () from /usr/lib64/libgtk-x11-2.0.so.0 #24 0x00007ffff6775395 in g_closure_invoke () from /usr/lib64/libgobject-2.0.so.0 #25 0x00007ffff6788a16 in ?? () from /usr/lib64/libgobject-2.0.so.0 #26 0x00007ffff679113c in g_signal_emit_valist () from /usr/lib64/libgobject-2.0.so.0 #27 0x00007ffff6791acf in g_signal_emit () from /usr/lib64/libgobject-2.0.so.0 #28 0x00007ffff782ca79 in ?? () from /usr/lib64/libgtk-x11-2.0.so.0 #29 0x00007ffff78daa58 in ?? () from /usr/lib64/libgtk-x11-2.0.so.0 #30 0x00007ffff6775395 in g_closure_invoke () from /usr/lib64/libgobject-2.0.so.0 #31 0x00007ffff67883c9 in ?? () from /usr/lib64/libgobject-2.0.so.0 #32 0x00007ffff6790b34 in g_signal_emit_valist () from /usr/lib64/libgobject-2.0.so.0 #33 0x00007ffff6791acf in g_signal_emit () from /usr/lib64/libgobject-2.0.so.0 #34 0x00007ffff79fa194 in ?? () from /usr/lib64/libgtk-x11-2.0.so.0 #35 0x00007ffff78d8ebc in gtk_propagate_event () from /usr/lib64/libgtk-x11-2.0.so.0 #36 0x00007ffff78d92e3 in gtk_main_do_event () from /usr/lib64/libgtk-x11-2.0.so.0 #37 0x00007ffff754a5ec in ?? () from /usr/lib64/libgdk-x11-2.0.so.0 #38 0x00007ffff649ecae in g_main_context_dispatch () from /usr/lib64/libglib-2.0.so.0 #39 0x00007ffff649eef0 in ?? () from /usr/lib64/libglib-2.0.so.0 #40 0x00007ffff649f212 in g_main_loop_run () from /usr/lib64/libglib-2.0.so.0 #41 0x00007ffff78d8207 in gtk_main () from /usr/lib64/libgtk-x11-2.0.so.0 #42 0x00005555555d33b7 in main (argc=, argv=) at main.c:275

inode64 avatar Jul 04 '18 09:07 inode64

If you could attach the failing gpx file (or directly message me it to: rw underscore norris at hotmail dot com - as listed in many of the source files) that would be great help.

rnorris avatar Jul 04 '18 22:07 rnorris

Ok, I sent some examples gpx.zip

inode64 avatar Jul 05 '18 07:07 inode64

I don't think I have a system with a security hardened "__fortify_fail ()" enabled, (or Viking doesn't trigger it for me). Hopefully the change incorporated above should address this issue. It would be great if you (inode64) could test with the latest source code to confirm this has fixed it.

rnorris avatar Jul 08 '18 11:07 rnorris

I'm Sorry, It Has failed yet :-(

inode64 avatar Jul 08 '18 14:07 inode64

And It fails with files .gpx or .vik

inode64 avatar Jul 08 '18 15:07 inode64

Can you please tell me which OS & Version you are using?

Hopefully then I'll be able to reproduce it locally, e.g. in a virtual machine and investigate deeper, as ATM I don't really understand why it would be failing.

rnorris avatar Jul 08 '18 17:07 rnorris

This is my system.

Portage 2.3.40 (python 2.7.14-final-0, default/linux/amd64/17.0/desktop/gnome, gcc-7.3.0, glibc-2.26-r7, 4.14.35-gentoo x86_64)

System uname: Linux-4.14.35-gentoo-x86_64-AMD_FX-tm-6100_Six-Core_Processor-with-gentoo-2.4.1 KiB Mem: 16453528 total, 5557052 free KiB Swap: 2104472 total, 330500 free Timestamp of repository gentoo: Mon, 09 Jul 2018 14:00:01 +0000 Head commit of repository gentoo: 77f0dfa9e5769421d4f4a542dc5ffe6551068c01 sh bash 4.4_p12 ld GNU ld (Gentoo 2.30 p2) 2.30.0 ccache version 3.3.4 [enabled] app-shells/bash: 4.4_p12::gentoo dev-java/java-config: 2.2.0-r4::gentoo dev-lang/perl: 5.24.3-r1::gentoo dev-lang/python: 2.7.14-r1::gentoo, 3.6.5::gentoo dev-util/ccache: 3.3.4-r1::gentoo dev-util/cmake: 3.9.6::gentoo dev-util/pkgconfig: 0.29.2::gentoo sys-apps/baselayout: 2.4.1-r2::gentoo sys-apps/openrc: 0.34.11::gentoo sys-apps/sandbox: 2.13::gentoo sys-devel/autoconf: 2.13::gentoo, 2.69-r4::gentoo sys-devel/automake: 1.11.6-r3::gentoo, 1.13.4-r2::gentoo, 1.15.1-r2::gentoo sys-devel/binutils: 2.30-r2::gentoo sys-devel/gcc: 7.3.0-r3::gentoo sys-devel/gcc-config: 1.8-r1::gentoo sys-devel/libtool: 2.4.6-r3::gentoo sys-devel/make: 4.2.1::gentoo sys-kernel/linux-headers: 4.13::gentoo (virtual/os-headers) sys-libs/glibc: 2.26-r7::gentoo

inode64 avatar Jul 09 '18 15:07 inode64

Can you specify what the compiler options you use for Viking are please?

rnorris avatar Jul 12 '18 20:07 rnorris

-O2 -march=k8-sse3 -pipe -msahf -mcx16 -mno-3dnow and make -j6 My CPU is a AMD FX(tm)-6100 Six-Core Processor but I when used -march=native is same result :-(

inode64 avatar Jul 13 '18 07:07 inode64

I'm sorry but I don't really have the time or inclination to get working a Gentoo setup (my initial attempts didn't work in a VM). So without fully understanding why the program fails with the initial stack trace, a work around would be for the latest code in file.c around line 684:

gchar *absolute = file_realpath_dup ( filename );

-->

gchar *absolute = NULL;

Hopefully that should stop it crashing, but with the caveat that loading DEM files / Waypoint Images etc.. that are referenced via a relative file path wouldn't work. [Since it now doesn't know what it's relative to]

rnorris avatar Aug 26 '18 10:08 rnorris