Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

buffer overflow detected after commit 8a439f317d60281cdb3f6dab57dd51b7315a90de #46

Open
inode64 opened this issue Jul 4, 2018 · 10 comments
Open

buffer overflow detected after commit 8a439f317d60281cdb3f6dab57dd51b7315a90de #46

inode64 opened this issue Jul 4, 2018 · 10 comments

Comments

@inode64
Copy link

inode64 commented Jul 4, 2018

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
@rnorris
Copy link
Collaborator

rnorris commented Jul 4, 2018

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.

@inode64
Copy link
Author

inode64 commented Jul 5, 2018

Ok, I sent some examples
gpx.zip

rnorris added a commit to rnorris/viking that referenced this issue Jul 8, 2018
@rnorris
Github Issue viking-gps#46: Better use of realpath()
b1be4e1 
Use system memory allocation by realpath() when available.
This should address custom allocation issue which seems to trigger "__fortify_fail()",
 possibly on systems with glibc built with security 'hardening' flags.
@rnorris
Copy link
Collaborator

rnorris commented Jul 8, 2018

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.

@inode64
Copy link
Author

inode64 commented Jul 8, 2018

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

@inode64
Copy link
Author

inode64 commented Jul 8, 2018

And It fails with files .gpx or .vik

@rnorris
Copy link
Collaborator

rnorris commented Jul 8, 2018

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.

@inode64
Copy link
Author

inode64 commented Jul 9, 2018

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

@rnorris
Copy link
Collaborator

rnorris commented Jul 12, 2018

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

@inode64
Copy link
Author

inode64 commented Jul 13, 2018

-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 :-(

@rnorris
Copy link
Collaborator

rnorris commented Aug 26, 2018

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]

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@rnorris @inode64