libgimp: plugins: valgrind shows invalid read on Wayland re remote window handle
Environment/Versions
- GIMP version: latest master
- Package: self-built
- Operating System: Linux Wayland
Description of the bug
If you run extension-script-fu under valgrind tool, valgrind reports:
==520== Invalid read of size 1
==520== at 0x484BEB4: strlen (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==520== by 0x671B5F6: wl_proxy_marshal_array_flags (in /usr/lib/x86_64-linux-gnu/libwayland-client.so.0.22.0)
==520== by 0x671BF58: wl_proxy_marshal_flags (in /usr/lib/x86_64-linux-gnu/libwayland-client.so.0.22.0)
==520== by 0x5CAF6FB: gdk_wayland_window_set_transient_for_exported (in /usr/lib/x86_64-linux-gnu/libgdk-3.so.0.2406.32)
==520== by 0x48B1378: gimp_window_transient_on_mapped (../gimp/libgimp/gimpui.c:373)
==520== by 0x4E38E9B: ??? (in /usr/lib/x86_64-linux-gnu/libgtk-3.so.0.2406.32)
==520== by 0x4C0912F: g_closure_invoke (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.7800.0)
==520== by 0x4C36818: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.7800.0)
==520== by 0x4C27311: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.7800.0)
==520== by 0x4C27BD5: g_signal_emit_valist (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.7800.0)
==520== by 0x4C27C92: g_signal_emit (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.7800.0)
==520== by 0x50EB153: ??? (in /usr/lib/x86_64-linux-gnu/libgtk-3.so.0.2406.32)
==520== Address 0x8b53320 is 0 bytes after a block of size 32 alloc'd
==520== at 0x484A993: calloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==520== by 0x4CB97E9: g_malloc0 (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7800.0)
==520== by 0x4BD4AB7: _gp_params_read (../gimp/libgimpbase/gimpprotocol.c:1995)
==520== by 0x4BD3CD8: _gp_proc_return_read (../gimp/libgimpbase/gimpprotocol.c:983)
==520== by 0x4BD65FD: gimp_wire_read_msg (../gimp/libgimpbase/gimpwire.c:264)
==520== by 0x4B6BBC4: _gimp_plug_in_read_expect_msg (../gimp/libgimp/gimpplugin.c:885)
==520== by 0x4B6A778: _gimp_pdb_run_procedure_array (../gimp/libgimp/gimppdb.c:465)
==520== by 0x4B8C02E: gimp_progress_get_window_handle (../gimp/libgimp/gimpprogress_pdb.c:245)
==520== by 0x48B131E: gimp_window_transient_on_mapped (../gimp/libgimp/gimpui.c:362)
==520== by 0x4E38E9B: ??? (in /usr/lib/x86_64-linux-gnu/libgtk-3.so.0.2406.32)
==520== by 0x4C0912F: g_closure_invoke (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.7800.0)
==520== by 0x4C36818: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.7800.0)
Interpreting: wayland is calling strlen() and reading beyond an allocation that is expected to have a NUL byte terminating a sequence of bytes. In Wayland, a window ID is a string. The string was allocated in gimp_window_transient_on_mapped().
The Wayland documentation is not always clear that it is a NUL-terminated string, but if the code is calling strlen() on it, it must be.
This is about plugins setting their dialogs transient to (on top of) the main gimp window (or the progress window) in another process. The window ID crosses the wire as a GBytes. A GBytes is not necessarily a NUL-terminated string, but it can be.
Reproduction
Is the bug reproducible? Always
On Wayland, run extension-script-fu in valgrind:
export GIMP_PLUGIN_DEBUG_WRAP=script-fu
export GIMP_PLUGIN_DEBUG_WRAPPER="valgrind"
and choose say Filters>Decor>Add Bevel
Expected result: no valgrind reports, and plugin dialog window stays on top
Actual result: as above, and plugin dialog will go behind main window
Additional information
I am not sure of any other symptoms. When I found this, I was exploring plugins dialogs failing to open, or failing to get focus when they were clicked, on Wayland.
Suggested fix
In libgimpwidgets/gimpwidgetsutils.c line 1197
wayland_handle = g_bytes_new (handle, strlen (handle));
=>
wayland_handle = g_bytes_new (handle, strlen (handle) + 1);
Ensures the GBytes contains the NUL terminator.