In Viking, when moving the map with the mouse, I got a
segmentation fault in gdk_pixbuf_get_n_channels.
Since images come from the network, this is potentially a
security issue (depending on the currently unknown cause
of the segmentation fault).
$ gdb /usr/bin/viking core.384824
GNU gdb (Debian 17.2-1+b1) 17.2
Copyright (C) 2025 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/bin/viking...
Reading symbols from /usr/lib/debug/.build-id/be/4156d4e9ba8690465a6c544fac61ffa47f3fb2.debug...
⚠ warning: Can't open file /memfd:glycin-frame (deleted) during file-backed mapping note processing
⚠ warning: Can't open file /home/vinc17/.local/share/gvfs-metadata/root-325986fa.log (deleted) during file-backed mapping note processing
⚠ warning: Can't open file /home/vinc17/.local/share/gvfs-metadata/root (deleted) during file-backed mapping note processing
[New LWP 384824]
[New LWP 385197]
[New LWP 384825]
[New LWP 384827]
[New LWP 384829]
[New LWP 384828]
[New LWP 385186]
[New LWP 384826]
[New LWP 384830]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `/usr/bin/viking 20100523.gpx 20110808.gpx 20170813.gpx 20190622.gpx 20190623a.gpx 20190623b.gpx 20190624.gpx 20190626.gpx 20190816.gpx 20201223.gpx 20201227.gpx 20210103.gpx 20210327.gpx 20210328.gpx 20210329.gpx 20210330.gpx 20210331.gpx 20210401.gpx 20210402.gpx 20210403.gpx 20210404.gpx 20210405.gpx 20210406.gpx 20210409.gpx 20210417.gpx 20210424.gpx 20210425.gpx 20210502.gpx 20210511.gpx 20210513.gpx 20211221a.gpx 20211221b.gpx 20211222.gpx 20211230.gpx 20220101a.gpx 20220101b.gpx 20220429.gpx 20220430a.gpx 20220430b.gpx 20220501.gpx 20220503.gpx 20220811a.gpx 20220811b.gpx 20220812.gpx 20221223a.gpx 20221223b.gpx 20221224.gpx 20230805.gpx 20230807a.gpx 20230807b.gpx 20230809a.gpx 20230809b.gpx 20231222a.gpx 20231222b.gpx 20231223.gpx 20231224a.gpx 20231224b.gpx 20231225.gpx 20231228.gpx 20231229.gpx 20240101a.gpx 20240101b.gpx 20240102.gpx 20240103.gpx 20240428.gpx 20240429.gpx 20240608a.gpx 20240608b.gpx 20240614a.gpx 20240614b.gpx 20240615.gpx 20240616.gpx 20240814.gpx 20240816.gpx 20240817.gpx 20240818a.gpx 20240818b.gpx 20241025a.gpx 20241025b.gpx 20241025c.gpx 20241026a.gpx 20241026b.gpx 20241027a.gpx 20241027b.gpx 20241027c.gpx 20241101.gpx 20241102.gpx 20241103.gpx 20241221a.gpx 20241221b.gpx 20241228.gpx 20250101.gpx 20250102a.gpx 20250102b.gpx 20250103.gpx 20250426a.gpx 20250426b.gpx 20250428.gpx 20250429.gpx 20250430.gpx 20250501.gpx 20250819.gpx 20251226a.gpx 20251226b.gpx 20251227.gpx 20251228a.gpx 20251228b.gpx 20251229.gpx 20260809a.gpx 20260809b.gpx 20260809c.gpx 20260810.gpx 20260811.gpx 20260812.gpx'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x00007f6fe52d0375 in gdk_pixbuf_get_n_channels (
pixbuf=pixbuf@entry=0x55683841303d) at ../gdk-pixbuf/gdk-pixbuf.c:774
⚠ warning: 774 ../gdk-pixbuf/gdk-pixbuf.c: No such file or directory
[Current thread is 1 (Thread 0x7f6fdcbef040 (LWP 384824))]
I've attached the full backtrace.
Control: retitle -1 viking: Segmentation fault in gdk_pixbuf_get_n_channels
Control: reassign -1 viking
Control: severity -1 important
Here is the entire code for gdk_pixbuf_get_n_channels():
int
gdk_pixbuf_get_n_channels (const GdkPixbuf *pixbuf)
{
g_return_val_if_fail (GDK_IS_PIXBUF (pixbuf), -1);
return pixbuf->n_channels;
}
The only way I can see for this to segfault is if pixbuf is not a valid
pointer, meaning that dereferencing its GTypeInstance->g_class or
GdkPixbuf->n_channels fails. This would point to a memory-management
problem in the calling program, most likely an uninitialized or dangling
pointer, perhaps involving a use-after-free of some larger object.
In the backtrace, the GdkPixbuf pointer can be seen to be
0x55683841303d, which cannot possibly be a validly allocated GdkPixbuf:
you'll notice the numeric value of the pointer is an odd number, but
every instance of a GObject subclass is allocated at a "naturally
aligned" address (at least 8 bytes alignment, but more likely 16 on
amd64) so the last hex-digit of any valid object pointer needs to be 0,
or perhaps rarely 8. This looks like uninitialized or corrupted memory
being interpreted as though it was a pointer to GdkPixbuf.
At the risk of stating the obvious, passing a pointer that is not a
valid GdkPixbuf * to gdk_pixbuf_get_n_channels() is undefined behaviour,
and gdk-pixbuf cannot guarantee any specific result if that happens.
Modern versions of gdk-pixbuf delegate parsing of
potentially-attacker-controlled image data to glycin, which carries out
this parsing in a sandboxed subprocess, and then operate on uncompressed
images in a simpler format, so this seems unlikely to be a security
issue in gdk-pixbuf's image parsing: if that was crashing anything, it
would be the sandboxed subprocess that crashed.
(And if you believe you have found an undisclosed security
vulnerability, immediately reporting it in public is probably not a
great idea.)
smcv
Control: tags -1 upstream Control: forwarded -1 https://github.com/viking-gps/viking/issues/393 Thanks. Since the viking Debian package only has unrelated patches, this is an upstream bug, which I've just reported.