gio/gdbusauth.c | 50 31 + 19 - 0 !
1 file changed, 31 insertions(+), 19 deletions(-)

 gdbus: never buffer reads during server authentication

Otherwise, the content of the buffer is thrown away when switching
from reading via a GDataInputStream to unbuffered reads when waiting
for the "BEGIN" line.

(The code already tried to protect against over-reading like this by
using unbuffered reads for the last few lines of the auth protocol,
but it might already be too late at that point.  The buffer of the
GDataInputStream might already contain the "BEGIN" line for example.)

This matters when connecting a sd-bus client directly to a GDBus
client.  A sd-bus client optimistically sends the whole auth
conversation in one go without waiting for intermediate replies.  This
is done to improve performance for the many short-lived connections
that are typically made.

Bug: https://gitlab.gnome.org/GNOME/glib/-/issues/2916

gio/gdbusinterfaceskeleton.c | 15 7 + 8 - 0 !
1 file changed, 7 insertions(+), 8 deletions(-)

 gdbusinterfaceskeleton: remove an unnecessary helper struct member
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit

The `GDBusInterfaceSkeleton` is already stored as the source object of
the `GTask` here, with a strong reference.

Storing it again in the tasks data struct is redundant, and makes it
look like the `GDBusInterfaceSkeleton` is being used without holding a
strong reference. (Theres not actually a bug there though: the strong
reference from the `GTask` outlives the data struct, so is sufficient.)

Remove the unnecessary helper struct member to clarify the code a bit.

Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Bug: https://gitlab.gnome.org/GNOME/glib/-/issues/2924

gio/gdbusinterfaceskeleton.c | 9 6 + 3 - 0 !
1 file changed, 6 insertions(+), 3 deletions(-)

 gdbusinterfaceskeleton: fix a use-after-free of a
 GDBusMethodInvocation
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit

This `GDBusMethodInvocation` may be shared across threads, with no
guarantee on the strong ref in one thread outlasting any refs in other
threads  so it needs a ref in this helper struct.

This should fix a use-after-free where the `GDBusMethodInvocation` is
freed from `g_value_unset()` after `g_signal_emit()` returns in
`dispatch_in_thread_func()` in one thread; but then dereferenced again
in `g_source_destroy_internal()` from another thread.

Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Bug: https://gitlab.gnome.org/GNOME/glib/-/issues/2924

gio/gdbusconnection.c | 2 1 + 1 - 0 !
1 file changed, 1 insertion(+), 1 deletion(-)

 gdbusconnection: make gdbusmethodinvocation transfer a bit clearer

Add a missing steal call in `schedule_method_call()`. This introduces no
functional changes, but documents the ownership transfer more clearly.

Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Bug: https://gitlab.gnome.org/GNOME/glib/-/issues/2924

gio/gdbusauth.c | 2 1 + 1 - 0 !
1 file changed, 1 insertion(+), 1 deletion(-)

 gdbus: fix an accidental string freeze break

Commit d982c8607 accidentally broke the string freeze on `glib-2-74` by
adding a new translatable string.

We can avoid that by reusing an existing string which has a similar
meaning.

Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Bug: https://gitlab.gnome.org/Teams/Translation/Coordination/-/issues/47

glib/tests/assert-msg-test.py | 6 3 + 3 - 0 !
1 file changed, 3 insertions(+), 3 deletions(-)

 tests: skip assert-msg-test.py if gdb fails

Similar to commit 6e44151bf74d, skip the test if gdb is unable to read
/proc/PID/mem, which gdb does as a fallback if ptrace is unavailable.

This allows the test to skip when run under Gentoo's sandbox.

(cherry picked from commit 19a8df9d8bff279a55b0fa3bb7ba4fbf7fcbefa8)

glib/tests/spawn-test.c | 11 10 + 1 - 0 !
1 file changed, 10 insertions(+), 1 deletion(-)

 =?utf-8?q?tests=3a_don=e2=80=99t_rely_on_output_locale_of_sort_in_?=
 =?utf-8?q?spawn-test?=

Otherwise the test will fail when run in a non-English locale.

Fix suggested by Simon McVittie.

Signed-off-by: Philip Withnall <pwithnall@endlessos.org>

Bug: https://gitlab.gnome.org/GNOME/glib/-/issues/2754

glib/gkeyfile.c | 83 83 + 0 - 0 !
1 file changed, 83 insertions(+)

 call gettext if .desktop file does not have inline translations

Patch from OpenSUSE via Ubuntu, original author unknown. Martin Pitt and
Vincent Untz appear to be the main authors.

Reworked slightly by Philip Withnall to avoid exposing new public API
for the non-standard keys.

Bug: https://bugzilla.gnome.org/show_bug.cgi?id=569829
Bug-Ubuntu: https://launchpad.net/bugs/3935

glib/tests/timer.c | 4 2 + 2 - 0 !
1 file changed, 2 insertions(+), 2 deletions(-)

 timer test: use 'volatile' for locals

GCC seems to be failing to follow the letter of the C spec by allowing extra
precision in floating point values to persist across assignments which are
optimised away.

Force its hand by using 'volatile' on the locals in question.

Bug: https://gitlab.gnome.org/GNOME/glib/issues/820

glib/tests/gwakeuptest.c | 17 13 + 4 - 0 !
1 file changed, 13 insertions(+), 4 deletions(-)

 gwakeuptest: be less parallel unless invoked with -m slow

This is a workaround for test failures on the reproducible-builds
infrastructure, where a multi-threaded stress-test sometimes takes longer
to finish on x86_64 than it would have done on slow architectures like
arm and mips on the official Debian autobuilders. It is not clear why.

This change will make this test more likely to pass, but less likely to
detect bugs.

Signed-off-by: Simon McVittie <smcv@debian.org>
Bug-Debian: https://bugs.debian.org/884659

glib/gkeyfile.c | 20 20 + 0 - 0 !
1 file changed, 20 insertions(+)

 provide backwards compatibility for 01_gettext-desktopfiles.patch
 for X-{Debian,Ubuntu}-Gettext-Domain

Ubuntu-specific. 01_gettext-desktopfiles.patch was changed to use
X-GNOME-, so this is necessary until all our .desktop files are converted.

gio/glib-compile-schemas.c | 4 4 + 0 - 0 !
1 file changed, 4 insertions(+)

 disable confusing (to users) warning about deprecated schema paths

Disable a warning when compiling schemas which are installed
into 'deprecated' locations. Users see this very often due to
glib-compile-schemas being called from libglib2.0-0's trigger and it is
not very useful for them.

glib/tests/thread.c | 9 8 + 1 - 0 !
1 file changed, 8 insertions(+), 1 deletion(-)

 do not fail the /thread/thread4 test if prlimit() fails

This happens on the Debian buildds.

[smcv: Use g_test_skip()]

gobject/tests/closure-refcount.c | 8 8 + 0 - 0 !
1 file changed, 8 insertions(+)

 closures test: skip on arm* unless flaky tests are allowed

Choosing the right number of iterations to avoid either taking literally
hours on some hardware, or getting spurious failures when one thread
starves another, seems to be too hard to get right in practice.
Make this test opt-in so that its failures aren't release-critical.
We can run it as a separate autopkgtest that is marked flaky.

Signed-off-by: Simon McVittie <smcv@debian.org>
Bug-Debian: https://bugs.debian.org/880883
Bug-Debian: https://bugs.debian.org/917983

glib/tests/mainloop.c | 16 16 + 0 - 0 !
glib/tests/timeout.c | 9 9 + 0 - 0 !
gobject/tests/threadtests.c | 8 8 + 0 - 0 !
3 files changed, 33 insertions(+)

 disable some tests on slow architectures which keep failing the
 tests

[smcv: Modified to use g_test_skip() instead of omitting those test cases
completely, and allow them to be re-enabled with a Debian-specific
environment variable]

Co-authored-by: Simon McVittie <smcv@debian.org>

glib/tests/timer.c | 6 6 + 0 - 0 !
1 file changed, 6 insertions(+)

 skip test which performs some unreliable floating point comparisons

[smcv: Modified to use g_test_skip() instead of omitting those test cases
completely, and allow them to be re-enabled with a Debian-specific
environment variable]

Co-authored-by: Simon McVittie <smcv@debian.org>
Bug: https://gitlab.gnome.org/GNOME/glib/issues/820

gio/tests/gdbus-threading.c | 6 6 + 0 - 0 !
1 file changed, 6 insertions(+)

 skip unreliable gdbus-threading tests by default

test_threaded_singleton() test to reproduce a race condition between
last-unref of the global singleton GDBusConnection and g_bus_get_sync().

test_method_calls_in_thread() checks that multiple threads can all make
method calls to the same proxy.

However, test setup intermittently times out with:

    # GLib-GIO-DEBUG: run 0: refcount is 2, sleeping
    Bail out! GLib-GIO-FATAL-ERROR: connection had too many refs

The current theory upstream is that this might be a reference leak in
test_delivery_in_thread().

Furthermore, test teardown is now often failing when destroying the test
bus.

Demote these tests to be run as part of the "flaky" autopkgtests, but
not at build time or in the part of the autopkgtest run that gates
progress into testing.

Bug: https://gitlab.gnome.org/GNOME/glib/issues/1515

gio/tests/gmenumodel.c | 6 6 + 0 - 0 !
1 file changed, 6 insertions(+)

 gmenumodel test: mark as flaky

This test has not had a great history of reliability.

Signed-off-by: Simon McVittie <smcv@debian.org>
Bug-Debian: https://bugs.debian.org/932678

glib/tests/gvariant.c | 8 8 + 0 - 0 !
1 file changed, 8 insertions(+)

 gvariant test: don't run at build-time on mips

DEB_ALLOW_FLAKY_TESTS is not quite right here, because we don't know
that the test would fail if left for long enough - the problem is that
it doesn't get there, because generating random floating-point numbers
is very slow on some of our mips hardware. However, it has the right
practical effect.

Signed-off-by: Simon McVittie <smcv@debian.org>
Bug: https://bugs.debian.org/932678

gio/tests/gdbus-server-auth.c | 7 7 + 0 - 0 !
1 file changed, 7 insertions(+)

 gdbus-server-auth: normally skip flaky dbus_cookie_sha1 tests

These intermittently fail on the buildds, but the failure cannot be
reproduced in a debugging environment.

We do not expect to use D-Bus over TCP on non-Windows platforms: we use
an AF_UNIX socket, which is much more robust and secure. However, when
using AF_UNIX, DBUS_COOKIE_SHA1 is unnecessary, because we can use the
more reliable EXTERNAL authentication.

gio/tests/memory-monitor-dbus.py.in | 2 2 + 0 - 0 !
1 file changed, 2 insertions(+)

 skip memory-monitor-dbus test if not specifically requested

This seems to be unreliable, particularly on non-x86.

Bug-Debian: https://bugs.debian.org/995178

gio/tests/memory-monitor-dbus.py.in | 18 16 + 2 - 0 !
1 file changed, 16 insertions(+), 2 deletions(-)

 add extra debug to memory-monitor-dbus test

Hopefully this will give us the necessary information to find out why
this test isn't reliable.

Bug-Debian: https://bugs.debian.org/995178

gio/tests/debugcontroller.c | 6 6 + 0 - 0 !
1 file changed, 6 insertions(+)

 tests: skip debugcontroller test

This is known to be flaky upstream.

gio/gdesktopappinfo.c | 2 2 + 0 - 0 !
1 file changed, 2 insertions(+)

 gdesktopappinfo: recognize gnome-console as a terminal app

GNOME Console (installed as /usr/bin/kgx ) is the default
GNOME terminal app as of GNOME 42

Related to: https://gitlab.gnome.org/GNOME/glib/-/issues/338

But see https://gitlab.freedesktop.org/xdg/xdg-specs/-/merge_requests/46
for a more comprehensive way of handling issues around the default
terminal app

gio/tests/testfilemonitor.c | 38 37 + 1 - 0 !
1 file changed, 37 insertions(+), 1 deletion(-)

 testfilemonitor: skip if we are avoiding flaky tests

See https://gitlab.gnome.org/GNOME/glib/issues/1634

Signed-off-by: Simon McVittie <smcv@debian.org>

gio/gdbusmessage.c | 35 22 + 13 - 0 !
1 file changed, 22 insertions(+), 13 deletions(-)

 gdbusmessage: cache the arg0 value
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit

Technically we cant rely on it being kept alive by the `message->body`
pointer, unless we can guarantee that the `GVariant` is always
serialised. Thats not necessarily the case, so keep a separate ref on
the arg0 value at all times.

This avoids a potential use-after-free.

Spotted by Thomas Haller in
https://gitlab.gnome.org/GNOME/glib/-/merge_requests/3720#note_1924707.

[This is a prerequisite for having tests pass after fixing the
vulnerability described in glib#3268, because after fixing that
vulnerability, the use-after-free genuinely does happen during
regression testing. -smcv]

Signed-off-by: Philip Withnall <pwithnall@gnome.org>

Helps: #3183, #3268
(cherry picked from commit 10e9a917be7fb92b6b27837ef7a7f1d0be6095d5)

gio/gdbusconnection.c | 1 1 + 0 - 0 !
glib/glib-private.h | 18 18 + 0 - 0 !
2 files changed, 19 insertions(+)

 gdbusconnection: make a backport of g_set_str() available

A subsequent commit will need this. Copying all of g_set_str() into a
private header seems cleaner than replacing the call to it.

Helps: GNOME/glib#3268
Signed-off-by: Simon McVittie <smcv@collabora.com>

gio/tests/gdbus-subscribe.c | 938 938 + 0 - 0 !
gio/tests/meson.build | 1 1 + 0 - 0 !
2 files changed, 939 insertions(+)

 tests: add a data-driven test for signal subscriptions

This somewhat duplicates test_connection_signals(), but is easier to

gio/tests/gdbus-subscribe.c | 133 126 + 7 - 0 !
1 file changed, 126 insertions(+), 7 deletions(-)

 tests: add support for subscribing to signals from a well-known name

Signed-off-by: Simon McVittie <smcv@collabora.com>

gio/tests/gdbus-subscribe.c | 48 48 + 0 - 0 !
1 file changed, 48 insertions(+)

 tests: add a test-case for what happens if a unique name doesn't
 exist

On GNOME/glib#3268 there was some concern about whether this would
allow an attacker to send signals and have them be matched to a
GDBusProxy in this situation, but it seems that was a false alarm.

Signed-off-by: Simon McVittie <smcv@collabora.com>

gio/tests/gdbus-subscribe.c | 161 154 + 7 - 0 !
1 file changed, 154 insertions(+), 7 deletions(-)

 tests: add test coverage for signals that match the message bus's
 name

This is a special case of unique names, even though it's syntactically
a well-known name.

Signed-off-by: Simon McVittie <smcv@collabora.com>

gio/gdbusprivate.h | 5 5 + 0 - 0 !
1 file changed, 5 insertions(+)

 gdbusprivate: add symbolic constants for the message bus itself

Using these is a bit more clearly correct than repeating them everywhere.

gio/gdbusconnection.c | 128 65 + 63 - 0 !
1 file changed, 65 insertions(+), 63 deletions(-)

 gdbusconnection: move signaldata, signalsubscriber higher up

Subsequent changes will need to access these data structures from
on_worker_message_received(). No functional change here, only moving
code around.

Signed-off-by: Simon McVittie <smcv@collabora.com>

gio/gdbusconnection.c | 42 32 + 10 - 0 !
1 file changed, 32 insertions(+), 10 deletions(-)

 gdbusconnection: factor out signal_data_new_take()

No functional changes, except that the implicit ownership-transfer
for the rule field becomes explicit (the local variable is set to NULL
afterwards).

Signed-off-by: Simon McVittie <smcv@collabora.com>

gio/gdbusconnection.c | 64 37 + 27 - 0 !
1 file changed, 37 insertions(+), 27 deletions(-)

 gdbusconnection: factor out add_signal_data()

No functional changes.

Signed-off-by: Simon McVittie <smcv@collabora.com>

gio/gdbusconnection.c | 83 48 + 35 - 0 !
1 file changed, 48 insertions(+), 35 deletions(-)

 gdbusconnection: factor out remove_signal_data_if_unused

No functional change, just removing some nesting. The check for whether
signal_data->subscribers is empty changes from a conditional that tests
whether it is into an early-return if it isn't.

A subsequent commit will add additional conditions that make us consider
a SignalData to be still in use and therefore not eligible to be removed.

Signed-off-by: Simon McVittie <smcv@collabora.com>

gio/gdbusconnection.c | 36 24 + 12 - 0 !
1 file changed, 24 insertions(+), 12 deletions(-)

 gdbusconnection: stop storing sender_unique_name in signaldata

This will become confusing when we start tracking the owner of a
well-known-name sender, and it's redundant anyway. Instead, track the
1 bit of data that we actually need: whether it's a well-known name.

Strictly speaking this too is redundant, because it's syntactically
derivable from the sender, but only via extra string operations.
A subsequent commit will add a data structure to keep track of the
owner of a well-known-name sender, at which point this boolean will
be replaced by the presence or absence of that data structure.

Signed-off-by: Simon McVittie <smcv@collabora.com>

gio/gdbusconnection.c | 350 343 + 7 - 0 !
1 file changed, 343 insertions(+), 7 deletions(-)

 gdbus: track name owners for signal subscriptions

We will use this in a subsequent commit to prevent signals from an
impostor from being delivered to a subscriber.

To avoid message reordering leading to misleading situations, this does
not use the existing mechanism for watching bus name ownership, which
delivers the ownership changes to other main-contexts. Instead, it all
happens on the single thread used by the GDBusWorker, so the order in
which messages are received is the order in which they are processed.

[Backported to glib-2-74, resolving minor conflicts]
Signed-off-by: Simon McVittie <smcv@collabora.com>

gio/gdbusconnection.c | 40 40 + 0 - 0 !
1 file changed, 40 insertions(+)

 gdbusconnection: don't deliver signals if the sender doesn't match

Otherwise a malicious connection on a shared bus, especially the system
bus, could trick GDBus clients into processing signals sent by the
malicious connection as though they had come from the real owner of a
well-known service name.

Resolves: https://gitlab.gnome.org/GNOME/glib/-/issues/3268
Signed-off-by: Simon McVittie <smcv@collabora.com>

gio/tests/gdbus-subscribe.c | 13 13 + 0 - 0 !
1 file changed, 13 insertions(+)

 tests: add a test for matching by two well-known names

The expected result is that because TEST_CONN_SERVICE owns
ALREADY_OWNED_NAME but not (yet) OWNED_LATER_NAME, the signal will be
delivered to the subscriber for the former but not the latter.
Before #3268 was fixed, it was incorrectly delivered to both.

Reproduces: https://gitlab.gnome.org/GNOME/glib/-/issues/3268 (partially)
Signed-off-by: Simon McVittie <smcv@collabora.com>

gio/tests/gdbus-subscribe.c | 27 27 + 0 - 0 !
1 file changed, 27 insertions(+)

 tests: add a test for signal filtering by well-known name

The vulnerability reported as GNOME/glib#3268 can be characterized
as: these signals from an attacker should not be delivered to either
the GDBusConnection or the GDBusProxy, but in fact they are (in at
least some scenarios).

Reproduces: https://gitlab.gnome.org/GNOME/glib/-/issues/3268
Signed-off-by: Simon McVittie <smcv@collabora.com>

gio/tests/gdbus-subscribe.c | 52 51 + 1 - 0 !
1 file changed, 51 insertions(+), 1 deletion(-)

 tests: ensure that unsubscribing with getnameowner in-flight doesn't
 crash

This was a bug that existed during development of this branch; make sure
it doesn't come back.

This test fails with a use-after-free and crash if we comment out the
part of name_watcher_unref_watched_name() that removes the name watcher
from `map_method_serial_to_name_watcher`.

It would also fail with an assertion failure if we asserted in
name_watcher_unref_watched_name() that get_name_owner_serial == 0
(i.e. that GetNameOwner is not in-flight at destruction).

Signed-off-by: Simon McVittie <smcv@collabora.com>

gio/tests/gdbus-proxy.c | 6 6 + 0 - 0 !
1 file changed, 6 insertions(+)

 gdbus-proxy test: wait before asserting name owner has gone away

GDBusConnection sends each signal to recipients in a separate idle
callback, and there's no particular guarantee about the order in which
they're scheduled or dispatched. For the NameOwnerChanged signal that
reports the name becoming unowned, it's possible that g_bus_watch_name()
gets its idle callback called before the GDBusProxy:g-name-owner
machinery has updated the name owner, in which case the assertion
will fail.

Fixing GNOME/glib#3268 introduced a new subscription to NameOwnerChanged
which can alter the order of delivery, particularly in the case where
G_DBUS_PROXY_FLAGS_NO_MATCH_RULE was used (as tested in
/gdbus/proxy/no-match-rule). The resulting test failure is intermittent,
but reliably appears within 100 repetitions of that test.

Fixes: 511c5f5b "tests: Wait for gdbus-testserver to die when killing it"
Signed-off-by: Simon McVittie <smcv@debian.org>

gio/gdbusconnection.c | 4 2 + 2 - 0 !
1 file changed, 2 insertions(+), 2 deletions(-)

 gdbusconnection: allow name owners to have the syntax of a
 well-known name

In a D-Bus-Specification-compliant message bus, the owner of a well-known
name is a unique name. However, ibus has its own small implementation
of a message bus (src/ibusbus.c) in which org.freedesktop.IBus is
special-cased to also have itself as its owner (like org.freedesktop.DBus
on a standard message bus), and connects to that bus with the
G_DBUS_CONNECTION_FLAGS_MESSAGE_BUS_CONNECTION flag. The ability to do
this regressed when CVE-2024-34397 was fixed.

Relax the checks to allow the owner of a well-known name to be any valid
D-Bus name, even if it is not syntactically a unique name.

Bug: https://gitlab.gnome.org/GNOME/glib/-/issues/3353
Bug-Debian: https://bugs.debian.org/1070730
Bug-Debian: https://bugs.debian.org/1070736
Bug-Debian: https://bugs.debian.org/1070743
Bug-Debian: https://bugs.debian.org/1070745
Signed-off-by: Simon McVittie <smcv@debian.org>

gio/gdbusmessage.c | 6 3 + 3 - 0 !
1 file changed, 3 insertions(+), 3 deletions(-)

 gdbusmessage: clean the cached arg0 when setting the message body

We're now caching arg0 but such value is not cleared when a new body is
set as it's in the connection filter test cases where we've a leak as
highlighted by both valgrind and leak sanitizer

gio/gsocks4aproxy.c | 4 2 + 2 - 0 !
1 file changed, 2 insertions(+), 2 deletions(-)

 gsocks4aproxy: fix a single byte buffer overflow in connect messages

`SOCKS4_CONN_MSG_LEN` failed to account for the length of the final nul
byte in the connect message, which is an addition in SOCKSv4a vs
SOCKSv4.

This means that the buffer for building and transmitting the connect
message could be overflowed if the username and hostname are both
`SOCKS4_MAX_LEN` (255) bytes long.

Proxy configurations are normally statically configured, so the username
is very unlikely to be near its maximum length, and hence this overflow
is unlikely to be triggered in practice.

(Commit message by Philip Withnall, diagnosis and fix by Michael
Catanzaro.)

CVE-2024-52533

Bug: https://gitlab.gnome.org/GNOME/glib/-/issues/3461
Bug-Debian: https://bugs.debian.org/1087419

glib/gdatetime.c | 12 8 + 4 - 0 !
1 file changed, 8 insertions(+), 4 deletions(-)

 gdatetime: fix integer overflow when parsing very long iso8601 inputs

This will only happen with invalid (or maliciously invalid) potential
ISO8601 strings, but `g_date_time_new_from_iso8601()` needs to be robust
against that.

Prevent `length` overflowing by correctly defining it as a `size_t`.
Similarly for `date_length`, but additionally track its validity in a
boolean rather than as its sign.

Spotted by chamalsl as #YWH-PGM9867-43.

Signed-off-by: Philip Withnall <pwithnall@gnome.org>

glib/gdatetime.c | 8 5 + 3 - 0 !
1 file changed, 5 insertions(+), 3 deletions(-)

 gdatetime: fix potential integer overflow in timezone offset handling

This one is much harder to trigger than the one in the previous commit,
but mixing `gssize` and `gsize` always runs the risk of the former
overflowing for very (very very) long input strings.

Avoid that possibility by not using the sign of the `tz_offset` to
indicate its validity, and instead using the return value of the
function.

Signed-off-by: Philip Withnall <pwithnall@gnome.org>

glib/gdatetime.c | 3 2 + 1 - 0 !
1 file changed, 2 insertions(+), 1 deletion(-)

 gdatetime: track timezone length as an unsigned size_t
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Its guaranteed to be in (0, length] by the calculations above.

This avoids the possibility of integer overflow through `gssize` not
being as big as `size_t`.

Signed-off-by: Philip Withnall <pwithnall@gnome.org>

glib/gdatetime.c | 18 10 + 8 - 0 !
1 file changed, 10 insertions(+), 8 deletions(-)

 gdatetime: factor out some string pointer arithmetic
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Makes the following code a little clearer, but doesnt introduce any
functional changes.

Signed-off-by: Philip Withnall <pwithnall@gnome.org>

glib/gdatetime.c | 13 6 + 7 - 0 !
1 file changed, 6 insertions(+), 7 deletions(-)

 gdatetime: factor out an undersized variable

For long input strings, it would have been possible for `i` to overflow.
Avoid that problem by using the `tz_length` instead, so that we count up
rather than down.

This commit introduces no functional changes (outside of changing
undefined behaviour), and can be verified using the identity
`i === length - tz_length`.

Signed-off-by: Philip Withnall <pwithnall@gnome.org>

glib/gstring.c | 36 23 + 13 - 0 !
1 file changed, 23 insertions(+), 13 deletions(-)

 gstring: carefully handle gssize parameters

Wherever we use gssize to allow passing -1, we need to ensure we don't
overflow the value by assigning a gsize to it without checking if the
size exceeds the maximum gssize. The safest way to do this is to just
use normal gsize everywhere instead and use gssize only for the
parameter.

Our computers don't have enough RAM to write tests for this. I tried
forcing string->len to high values for test purposes, but this isn't
valid and will just cause out of bounds reads/writes due to
string->allocated_len being unexpectedly small, so I don't think we can
test this easily.

(cherry picked from commit cc647f9e46d55509a93498af19659baf9c80f2e3)

Co-authored-by: Michael Catanzaro <mcatanzaro@redhat.com>
Bug: https://gitlab.gnome.org/GNOME/glib/-/issues/3677
Bug-CVE: CVE-2025-4373
Bug-Debian: https://bugs.debian.org/1104930

glib/gstring.c | 2 1 + 1 - 0 !
1 file changed, 1 insertion(+), 1 deletion(-)

 gstring: make len_unsigned unsigned

Bug: https://gitlab.gnome.org/GNOME/glib/-/issues/3677
Bug-CVE: CVE-2025-4373
Bug-Debian: https://bugs.debian.org/1104930

glib/gfileutils.c | 4 2 + 2 - 0 !
1 file changed, 2 insertions(+), 2 deletions(-)

 glib/gfileutils.c: use 64 bits for value in get_tmp_file()

On 32 bit systems 'long' value will overflow in 2038 and become negative.
As it is used to index into letters array, and % operation preserves signs,
data corruption will then occur.

[This change makes the patch for CVE-2025-7039 apply cleanly -smcv]

Signed-off-by: Alexander Kanavin <alex@linutronix.de>

glib/gfileutils.c | 8 4 + 4 - 0 !
1 file changed, 4 insertions(+), 4 deletions(-)

 gfileutils: fix computation of temporary file name

We need to ensure that the value we use to index into the letters array
is always positive.