This will catch regressions like
fc030b2b64 if they happen again in future,
by testing that fallback argument parsing code path in
`g_application_run()`.
Heavily based on the PyGObject `test_local_and_remote_command_line` unit
test at
578a55982a/tests/test_gio.py (L289).
Thanks to Arjan Molenaar for investigating the failure and writing it
up in !4703.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Do an extra check if the options argument is NULL,
This will avoid unnessecary (critical warning).
`g_application_run` calls the code with options == NULL.
The array buffer is of size BUFSIZE. The if-check correctly avoids
writing characters into the buffer, but the ending newline may still
overflow buffer. Keep space for the EOL character.
If an array with more than INT_MAX elements is passed to functions
internally calling g_build_path_va or g_build_pathname_va, then a
signed integer overflow and eventual out of boundary read access can
occur.
Use size_t instead of gint for lengths and array sizes.
The g_array_copy function uses elt_capacity as length argument for
g_array_sized_new. With a zero terminated array, this effectively
means that the next allocation is doubled in size.
Avoid this by doing the same as g_ptr_array_copy, i.e. use the length.
This makes sure that elt_capacity is roughly the same (only differs
if the copied array has unallocated data in it).
If supplied data argument is not NULL, then add the actually existing
null/zero terminated element to alloc/elt_capacity. Otherwise the
termination element is not taken into account, because the length only
counts the non-termination elements.
Purely defensive measurement. I don't think that this triggered any
bug (only one needless realloc call if set_size functions are called
with the current length).
The functions g_array_new and g_array_sized_new already protect
themselves against a zero element size.
Do the same in g_array_new_take and g_array_new_take_zero_terminated
to avoid a NULL pointer dereference and an endless loop.
Apply GArray's g_array_maybe_expand overflow checking logic to
GPtrArray's g_ptr_array_maybe_expand function:
Let g_ptr_array_maybe_expand handle the null_terminated flag internally
to check if an overflow occurs instead of letting callers do these
check on their own.
The g_ptr_array_copy function lacked this check.
Having a centralized position for this check simplifies the code and
further code auditings.
The functions g_array_new_take_zero_terminated and
g_ptr_array_new_take_null_terminated must take into account that the
last element will be the terminating element (zero filled or NULL).
Iterating through all elements must not reach G_MAXUINT, because in
that case no space is left for the terminating element.
Call these vfuncs also for cases where the launching instance
is the primary one. This is what the docs suggest, and it makes
before/after_emit much more useful.
Fixes: #3726
Existing uses of before_emit in GTK will break if an app overrides
before/after_emit without chaining up. Clarify in the documentation
that these vfuncs need to chain up.
The dbus-appinfo test was asserting that before_emit only happens
when we haven't seen a startup ID yet. But the docs imply that it
gets emitted for every activate/open/commandline, which may well
happen repeatedly. So drop this assertion.
The g_array_new_take_zero_terminated function could lead to NULL
data pointer if it is called with (NULL, FALSE, x), i.e. with a NULL
pointer and no clear request.
This in turn means that g_array_steal could behave like
g_ptr_array_steal, i.e. it would return NULL instead of a zero
terminated array, which does not match its description.
Also, g_array_remove_range and g_array_set_size could lead to NULL
pointer dereferences with such arrays.
Support all these cases and adjust the API description to reflect
current behavior. It brings GArray and GPtrArray functionality closer
to each other without breaking existing API/ABI for programs.
The g_string_append_vprintf function could overflow with strings
which are INT_MAX bytes long. The eventual memcpy call copies INT_MAX
plus additional nul byte into newly allocated memory. This means
that due to signed integer overflow more bytes are copied than
could ever fit.
The multiplication of two guint values could overflow with large
arrays. Use g_array_elt_len and g_array_elt_pos to avoid explicit
elt_size multiplications.
Tests currently fail under macOS because the tool claims not to work
on apple devices. Since I cannot disprove this myself, I'm disabling the
tests on Darwin.
As per the desktop entry specification, the `%k` field code should be
expanded to the location of the desktop entry file being processed. This
is only possible if the constructor-only filename property is populated,
which does not happen when using g_desktop_app_info_new_from_keyfile().
Moreover, since the Path directive in a desktop entry can be used to
set the working directory for the program to be launched, the location
passed as argument to the program must be modified such that it points
at the correct file when interpreted by the launched program. The
simplest way to achieve this consistently is to pass an absolute path.
However, g_desktop_app_info_new_from_keyfile() does not indicate why it
fails when it does. Because the tool aims to indicate whether launching
failed due to a missing file or a malformed one we first check this with
g_key_file_load_from_file().
This introduces an integration test that executes gio launch from a
variety of working directories, and checks that %k is expanded to a
location that makes sense in the context of the executed program, i.e.
an absolute path.
If a source is using g_source_set_callback_indirect(), then performing
GSource operations within GSourceCallbackFuncs::unref should not cause a
deadlock.
Fixes https://gitlab.gnome.org/GNOME/glib/-/issues/3725
Use the same style for the G_LIKELY check here as in g_string_sized_new.
The check could overflow on 32 bit systems.
Also improve the memcpy/memmove check to use memcpy if val itself is
adjacent to end + len_unsigned, which means that no overlapping exists.
If glib is compiled with -Dglib_assert=false, i.e. no asserts
enabled, then g_string_sized_new(G_MAXSIZE) leads to a segmentation
fault due to an out of boundary write.
This happens because the overflow check was moved into
g_string_maybe_expand which is not called by g_string_sized_new.
By assuming that string->allocated_len is always larger than
string->len (and the code would be in huge trouble if that is not true),
the G_UNLIKELY check in g_string_maybe_expand can be rephrased to
avoid a potential G_MAXSIZE overflow.
This in turn leads to 150-200 bytes smaller compiled library
depending on gcc and clang versions, and one less check for the most
common code paths.
Reverts https://gitlab.gnome.org/GNOME/glib/-/merge_requests/4655 and
reorders internal g_string_maybe_expand check to still fix
CVE-2025-6052.
