Debian Patches

Status for glib2.0/2.84.4-3~deb13u5

Patch Description Author Forwarded Bugs Origin Last update
01_gettext-desktopfiles.patch 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.		 Philip Withnall <withnall@endlessm.com> yes upstream 2017-11-23
debian/02_gettext-desktopfiles-ubuntu.patch 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.		 Martin Pitt <mpitt@debian.org> no 2009-02-24
debian/03_disble_glib_compile_schemas_warning.patch 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.		 Iain Lane <iain.lane@canonical.com> not-needed 2012-09-10
debian/gdesktopappinfo-Try-using-x-terminal-emulator-for-Termina.patch gdesktopappinfo: Try using x-terminal-emulator for Terminal=true apps

Debian Policy provides x-terminal-emulator as an interface for launching
a preferred terminal, for some definition of "preferred". However, the
x-terminal-emulator alternative is a system-wide choice, so in situations
where for example a GNOME user and a KDE user share a computer, only one
of them can have the terminal that will match their desktop environment's
appearance and behaviour conventions as the x-terminal-emulator.

As a result, we still try to use a GTK-based terminal as a higher
preference than x-terminal-emulator. This is done on the assumption
that when apps are launched using GLib interfaces, they are most likely
to have been launched from a GTK application or GTK-based desktop
environment, and therefore a GTK-based terminal will be the best fit for
the desktop environment's conventions and appearance.

I've somewhat arbitrarily sorted x-terminal-emulator as less preferred
than KDE's Konsole, but more preferred than rxvt and various xterm
variants which are not associated with a particular desktop environment.		 Simon McVittie <smcv@debian.org> not-needed debian 2023-02-04
workarounds/timer-test-use-volatile-for-locals.patch 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.		 Ryan Lortie <desrt@desrt.ca> yes upstream 2014-03-04
workarounds/gwakeuptest-Be-less-parallel-unless-invoked-with-m-slow.patch 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.		 Simon McVittie <smcv@debian.org> no debian 2017-12-18
workarounds/closures-test-Skip-on-arm-unless-flaky-tests-are-allowed.patch 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.		 Simon McVittie <smcv@debian.org> not-needed debian 2019-01-03
workarounds/Disable-some-tests-on-slow-architectures-which-keep-faili.patch 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]		 Martin Pitt <martin.pitt@ubuntu.com> no 2012-09-27
workarounds/Skip-test-which-performs-some-unreliable-floating-point-c.patch 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]		 Iain Lane <laney@debian.org> no upstream 2014-03-18
workarounds/Skip-unreliable-gdbus-threading-tests--by-default.patch 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.		 Simon McVittie <smcv@debian.org> no upstream 2019-01-04
workarounds/gvariant-test-Don-t-run-at-build-time-on-mips.patch 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.		 Simon McVittie <smcv@debian.org> no upstream 2019-07-26
workarounds/gdbus-server-auth-Normally-skip-flaky-DBUS_COOKIE_SHA1-te.patch 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.		 Simon McVittie <smcv@debian.org> not-needed 2020-11-19
workarounds/Skip-memory-monitor-dbus-test-if-not-specifically-request.patch Skip memory-monitor-dbus test if not specifically requested
This seems to be unreliable, particularly on non-x86.		 Simon McVittie <smcv@debian.org> no debian 2021-10-24
workarounds/tests-Skip-debugcontroller-test.patch tests: Skip debugcontroller test
This is known to be flaky upstream.		 Simon McVittie <smcv@debian.org> not-needed 2022-02-15
workarounds/testfilemonitor-Skip-if-we-are-avoiding-flaky-tests.patch testfilemonitor: Skip if we are avoiding flaky tests
See https://gitlab.gnome.org/GNOME/glib/issues/1634		 Simon McVittie <smcv@debian.org> no 2020-02-25
debian/girepository-Describe-the-Debian-specific-cross-prefixed-.patch girepository: Describe the Debian-specific cross-prefixed names Simon McVittie <smcv@debian.org> not-needed 2024-02-28
gfileutils-Preserve-mode-during-atomic-updates.patch gfileutils: Preserve mode during atomic updates
If g_file_set_contents{_full,} is replacing an existing file, require
that the tmpfile have the same mode as the existing file.

This prevents the umask from taking effect for consistent writes to
existing files.

Closes GNOME/dconf#76

(cherry picked from commit 3cc0c0de33bc4b461e89b05d142e1ecf5f474317)

it seems reasonable to keep it for trixie anyway
https://gitlab.gnome.org/GNOME/glib/-/merge_requests/4608		 Wesley Hershberger <wesley.hershberger@canonical.com> no upstream glib-2-84 branch, after 2.84.1 2025-04-22
gconvert-Error-out-if-g_escape_uri_string-would-overflow.patch gconvert: Error out if g_escape_uri_string() would overflow
If the string to escape contains a very large number of unacceptable
characters (which would need escaping), the calculation of the length of
the escaped string could overflow, leading to a potential write off the
end of the newly allocated string.

In addition to that, the number of unacceptable characters was counted
in a signed integer, which would overflow to become negative, making it
easier for an attacker to craft an input string which would cause an
out-of-bounds write.

Fix that by validating the allocation length, and using an unsigned
integer to count the number of unacceptable characters.

Spotted by treeplus. Thanks to the Sovereign Tech Resilience programme
from the Sovereign Tech Agency. ID: #YWH-PGM9867-134


Backport 2.86: Changed the translatable error message to re-use an
existing translatable string, to avoid adding new translatable strings
to a stable branch. The re-used string doesn’t perfectly match the
error, but it’s good enough given that no users will ever see it.		 Philip Withnall <pwithnall@gnome.org> yes debian upstream upstream, 2.86.3, commit:9bcd65ba5fa1b92ff0fb8380faea335ccef56253 2025-11-13
fuzzing-Add-fuzz-tests-for-g_filename_-to-from-_uri.patch fuzzing: Add fuzz tests for g_filename_{to,from}_uri()
These functions could be called on untrusted input data, and since they
do URI escaping/unescaping, they have non-trivial string handling code.		 Philip Withnall <pwithnall@gnome.org> yes debian upstream upstream, 2.86.3, commit:7e5489cb921d0531ee4ebc9938da30a02084b2fa 2025-11-13
gvariant-parser-Fix-potential-integer-overflow-parsing-by.patch gvariant-parser: Fix potential integer overflow parsing (byte)strings

The termination condition for parsing string and bytestring literals in
GVariant text format input was subject to an integer overflow for input
string (or bytestring) literals longer than `INT_MAX`.

Fix that by counting as a `size_t` rather than as an `int`. The counter
can never correctly be negative.

Spotted by treeplus. Thanks to the Sovereign Tech Resilience programme
from the Sovereign Tech Agency. ID: #YWH-PGM9867-145		 Philip Withnall <pwithnall@gnome.org> yes debian upstream upstream, 2.86.3, commit:3e72fe0fbb32c18a66486c4da8bc851f656af287 2025-11-25
gvariant-parser-Use-size_t-to-count-numbers-of-child-elem.patch gvariant-parser: Use size_t to count numbers of child elements
Rather than using `gint`, which could overflow for arrays (or dicts, or
tuples) longer than `INT_MAX`. There may be other limits which prevent
parsed containers becoming that long, but we might as well make the type
system reflect the programmer’s intention as best it can anyway.

For arrays and tuples this is straightforward. For dictionaries, it’s
slightly complicated by the fact that the code used
`dict->n_children == -1` to indicate that the `Dictionary` struct in
question actually represented a single freestanding dict entry. In
GVariant text format, that would be `{1, "one"}`.

The implementation previously didn’t define the semantics of
`dict->n_children < -1`.

Now, instead, change `Dictionary.n_children` to `size_t`, and define a
magic value `DICTIONARY_N_CHILDREN_FREESTANDING_ENTRY` to indicate that
the `Dictionary` represents a single freestanding dict entry.

This magic value is `SIZE_MAX`, and given that a dictionary entry takes
more than one byte to represent in GVariant text format, that means it’s
not possible to have that many entries in a parsed dictionary, so this
magic value won’t be hit by a normal dictionary. An assertion checks
this anyway.

Spotted while working on #3834.		 Philip Withnall <pwithnall@gnome.org> yes debian upstream upstream, 2.86.3, commit:6fe481cec709ec65b5846113848723bc25a8782a 2025-11-25
gvariant-parser-Convert-error-handling-code-to-use-size_t.patch gvariant-parser: Convert error handling code to use size_t
The error handling code allows for printing out the range of input bytes
related to a parsing error. This was previously done using `gint`, but
the input could be longer than `INT_MAX`, so it should really be done
using `size_t`.

Spotted while working on #3834.		 Philip Withnall <pwithnall@gnome.org> yes debian upstream upstream, 2.86.3, commit:dd333a40aa95819720a01caf6de564cd8a4a6310 2025-11-25
gfileattribute-Fix-integer-overflow-calculating-escaping-.patch gfileattribute: Fix integer overflow calculating escaping for byte strings

The number of invalid characters in the byte string (characters which
would have to be percent-encoded) was only stored in an `int`, which
gave the possibility of a long string largely full of invalid
characters overflowing this and allowing an attacker-controlled buffer
size to be allocated.

This could be triggered by an attacker controlled file attribute (of
type `G_FILE_ATTRIBUTE_TYPE_BYTE_STRING`), such as
`G_FILE_ATTRIBUTE_THUMBNAIL_PATH` or `G_FILE_ATTRIBUTE_STANDARD_NAME`,
being read by user code.

Spotted by Codean Labs.		 Philip Withnall <pwithnall@gnome.org> yes debian upstream upstream, 2.86.3, commit:4f0399c0aaf3ffc86b5625424580294bc7460404 2025-12-04
gtimezone-Handle-etc-localtime-symlink-pointing-to-anothe.patch gtimezone: Handle /etc/localtime symlink pointing to another symlink
To resolve a timezone identifier from /etc/localtime we should traverse its
symlink recursively until we find a target under $TZDIR, then the identifier
is that target minus the $TZDIR path prefix.		 Alessandro Astone <alessandro.astone@canonical.com> yes debian upstream upstream, 2.87.3, commit:7073c4872d96b78bfa9396b38e18e8043308550f 2026-01-20
gtimezone-Use-var-db-timezone-zoneinfo-as-the-default-TZD.patch gtimezone: Use /var/db/timezone/zoneinfo as the default TZDIR for macOS

macOS defines /usr/share/zoneinfo as a symlink to /var/db/timezone/zoneinfo,
and /etc/localtime as a symlink to /var/db/timezone/zoneinfo/<identifier>.

By using /usr/share/zoneinfo as TZDIR, we would break the logic that resolves
/etc/localtime as a relative identifier by stripping the TZDIR prefix.
An absolute path still works as identifier, but we prefer a relative one.

Furthermore, by ensuring that /etc/localtime points to a subdir of TZDIR we
correctly handle the case where /etc/localtime points to a symlink of symlink.		 Alessandro Astone <alessandro.astone@canonical.com> yes debian upstream upstream, 2.87.3, commit:bd04ea91dc533303c064ec1cb627844a4aa09aaf 2026-01-22
CVE-2026-0988.patch gbufferedinputstream: Fix a potential integer overflow in peek()
If the caller provides `offset` and `count` arguments which overflow,
their sum will overflow and could lead to `memcpy()` reading out more
memory than expected.

Spotted by Codean Labs.


(cherry picked from commit c5766cff61ffce0b8e787eae09908ac348338e5f)		 Philip Withnall <pwithnall@gnome.org> no 2025-12-18
CVE-2026-1484-1.patch gbase64: Use gsize to prevent potential overflow
Both g_base64_encode_step() and g_base64_encode_close() return gsize
values, but these are summed to an int value.

If the sum of these returned values is bigger than MAXINT, we overflow
while doing the null byte write.

Spotted by treeplus.
Thanks to the Sovereign Tech Resilience programme from the Sovereign
Tech Agency.


(cherry picked from commit 6845f7776982849a2be1d8c9b0495e389092bff2)

(cherry picked from commit 5ba0ed9ab2c28294713bdc56a8744ff0a446b59c)		 Marco Trevisan <mail@3v1n0.net> no 2026-01-23
CVE-2026-1484-2.patch gbase64: Ensure that the out value is within allocated size
We do not want to deference or write to it

Related to: #3870

(cherry picked from commit 25429bd0b22222d6986d000d62b44eebf490837d)		 "Marco Trevisan (Treviño)" <mail@3v1n0.net> no 2026-01-21
CVE-2026-1485.patch gio/gcontenttype-fdo: Do not overflow if header is longer than MAXINT

In case the header size is longer than MAXINT we may read and write to
invalid locations

Spotted by treeplus.
Thanks to the Sovereign Tech Resilience programme from the Sovereign
Tech Agency.


(cherry picked from commit aacda5b07141b944408c79e83bcbed3b2e1e6e45)

(cherry picked from commit ee5acb2cefc643450509374da2600cd3bf49a109)		 Marco Trevisan <mail@3v1n0.net> no 2026-01-23
CVE-2026-1489-1.patch guniprop: Use size_t for output_marks length
The input string length may overflow, and this would lead to wrong
behavior and invalid writes.

Spotted by treeplus.
Thanks to the Sovereign Tech Resilience programme from the Sovereign
Tech Agency.

(cherry picked from commit 662aa569efa65eaa4672ab0671eb8533a354cd89)		 "Marco Trevisan (Treviño)" <mail@3v1n0.net> no 2026-01-21
CVE-2026-1489-2.patch guniprop: Do not convert size_t to gint
We were correctly using size_t in output_special_case() since commit
362f92b69, but then we converted the value back to int

Related to: #3872

(cherry picked from commit 58356619525a1d565df8cc348e9784716f020f2f)		 "Marco Trevisan (Treviño)" <mail@3v1n0.net> no 2026-01-21
CVE-2026-1489-3.patch guniprop: Ensure we do not overflow size in g_utf8_{strdown,gstrup}()

While this is technically not a security issue, when repeatedly adding
to a size_t value, we can overflow and start from 0.

Now, while being unlikely, technically an utf8 lower or upper string can
have a longer size than the input value, and if the output string is
bigger than G_MAXSIZE we'd end up cutting it silently.

Let's instead assert each time we increase the output length

(cherry picked from commit 170dc8c4068db4c4cbf63c7d27192e230436da21)		 "Marco Trevisan (Treviño)" <mail@3v1n0.net> no 2026-01-21
CVE-2026-1489-4.patch glib/tests/unicode: Add test debug information when parsing input files

On case of failures makes it easier to understand on what line of the
source file we're at, as it might not be clear for non-ascii chars

(cherry picked from commit b96966058f4291db8970ced70ee22103e63679e5)		 "Marco Trevisan (Treviño)" <mail@3v1n0.net> no 2026-01-23
gvariant-Fix-an-off-by-one-error-in-an-offset-comparison.patch gvariant: Fix an off-by-one error in an offset comparison
This allows a single byte out-of-bounds read off the end of the
(potentially untrusted) byte array backing a `GVariant` when it’s
being checked for normal form.

I can’t see how this could practically be exploited, but it’s certainly
a security bug as the `GVariant` normal form checking code is supposed
to be robust to malicious inputs.

Spotted by linhlhq as #YWH-PGM9867-190, and fix and reproducer provided
by them too, thanks. Confirmed and turned into a unit test by me.		 Philip Withnall <pwithnall@gnome.org> yes upstream upstream, 2.86.5, commit:aa1cb87d56111ef989811e824f0ac77484cc997f 2026-03-29
gmarkup-Fix-potential-one-byte-overread-in-g_markup_escap.patch gmarkup: Fix potential one-byte overread in g_markup_escape_text()
If the input string (which might be malicious, as the program is
choosing to escape it) ends with 0xc2 (a UTF-8 prefix byte), the code
wasn’t previously checking the input string length was long enough to
contain the following byte before reading it.

Fix that by switching from `g_utf8_get_char()` to
`g_utf8_get_char_validated()`.

Spotted by linhlhq as #YWH-PGM9867-187. Thank you for the suggested fix
and unit test, which have been adapted into this commit.

Also spotted by oss-fuzz after we added a fuzz test for this function.


oss-fuzz#498475244		 Philip Withnall <pwithnall@gnome.org> yes upstream upstream, 2.86.5, commit:a316ec5005b1fd3b4ed7ae55603a844077862a06 2026-03-29
gdatetime-Factor-out-a-couple-of-magic-constants.patch gdatetime: Factor out a couple of magic constants
This introduces no functional changes, it just makes the code a little
clearer.		 Philip Withnall <pwithnall@gnome.org> yes upstream upstream, 2.86.5, commit:2521a538a5ff810d6d18ff3f5b105ee55419d694 2026-03-29
gdatetime-Add-missing-range-validation-to-g_date_time_add.patch gdatetime: Add missing range validation to g_date_time_add_full()
Otherwise it’s possible to create a non-`NULL` but invalid `GDateTime`,
which breaks all kinds of internal assumptions.

Spotted by linhlhq as #YWH-PGM9867-191. Thanks to them for providing a
suggested fix and a test case, which I have adapted and validated.		 Philip Withnall <pwithnall@gnome.org> yes upstream upstream, 2.86.5, commit:ae27363f025ffc131e2d75ee88a5cd8320dffe3b 2026-03-29
gregex-Fix-case-changing-substitutions-with-G_REGEX_RAW.patch gregex: Fix case changing substitutions with G_REGEX_RAW
In `G_REGEX_RAW` mode, the input string is treated as a byte array
(basically ASCII) rather than a unichar array. Accordingly, the case
changing code for substitutions needs to operate on bytes with
`G_REGEX_RAW`, rather than operating on unichars.

This fixes a potential buffer overflow when trying to do a case change
on a match of a set of bytes which are a truncated multi-byte UTF-8
encoding at the end of the input buffer.

Spotted by linhlhq as #YWH-PGM9867-193. I adapted their reproducer as
the unit test, but implemented the fix in `gregex.c` independently.		 Philip Withnall <pwithnall@gnome.org> yes upstream upstream, 2.86.5, commit:d337aabd24ee2b8ac2a690dba3ccf26aa70e638f 2026-03-31
gregex-Fix-use-of-wrong-option-flags-set-for-checking-for.patch gregex: Fix use of wrong option flags set for checking for G_REGEX_RAW

`GRegex.compile_opts` contains the options using PCRE2’s flags;
`GRegex.orig_compile_opts` contains them in `GRegexCompileFlags` format,
and that’s what we want here.

Spotted by linhlhq as #YWH-PGM9867-194. The suggested fix is theirs, and
the unit test is adapted from their report.		 Philip Withnall <pwithnall@gnome.org> yes upstream upstream, 2.86.5, commit:67775ba7e88a790c4639cca72e79317115f4a6f7 2026-03-31
gregex-Rename-the-compile_opts-members-to-clarify-their-t.patch gregex: Rename the `compile_opts` members to clarify their types
It’s easy to confuse `compile_opts` (`PCRE2_*` flags) and
`orig_compile_opts` (`GRegexCompileFlags` flags). Rename them to
`pcre2_compile_opts` and `regex_compile_opts`, respectively, to make it
a bit less confusing.

Unfortunately the type checker can’t help us here as the `PCRE2_*` flags
are defined by `pcre2` using `#define`s rather than an `enum`, so
`pcre2_compile_opts` has to stay as a `uint32_t` rather than a more
specific type.		 Philip Withnall <pwithnall@gnome.org> yes upstream upstream, 2.86.5, commit:3a76831c8a51c0e4d1e214a02760f98712916b3c 2026-03-31
giochannel-Fix-memcmp-off-the-end-of-the-buffer-with-long.patch giochannel: Fix memcmp() off the end of the buffer with long terminators

If the line terminator is longer than a single byte, and the current
line extends to the end of the buffer, and the buffer (which is a
`GString`) is near a power of two in length (as that’s how `GString`s
are allocated) it’s possible for the `memcmp()` which checks the
terminator to read off the end of the string buffer.

Fix that by checking the terminator length against the last character
before calling `memcmp()`. Add a unit test.

Spotted by linhlhq as #YWH-PGM9867-199. The fix is theirs (validated by
me), and the unit test is adapted from their proof of concept.

[smcv: Backport to 2.84.x by adding <stdint.h>]		 Philip Withnall <pwithnall@gnome.org> yes upstream backport, 2.88.1, commit:6a2583dec39bfe05553b16d9b7419d6c2a257244 2026-04-28
gkeyfile-Fix-a-one-byte-heap-under-read-with-g_key_file_g.patch gkeyfile: Fix a one-byte heap under-read with g_key_file_get_locale_string_list()

If this method was called on a key file key which has an empty value,
`len == 0` and this leads to a one-byte under-read off the start of the
key file buffer.

Spotted by linhlhq as #YWH-PGM9867-200. The suggested fix is theirs, and
the unit test is adapted from their report. I added the fuzzing test.		 Philip Withnall <pwithnall@gnome.org> yes upstream upstream, 2.88.1, commit:94ecb5b44a1cae09f481dd5e693832f129948893 2026-04-11
gdbusmessage-Fix-types-of-integer-arithmetic-in-message-l.patch gdbusmessage: Fix types of integer arithmetic in message length calculation

This fixes the addition happening with type `uint32_t`, rather than the
expected `gssize`. Because of the narrower type, this could have
resulted in integer overflow for large header lengths, bypassing the
message length check lower down in the function.

This is not exploitable in practice unless communicating peer-to-peer
with a malicious D-Bus peer, as invalid messages like this would be
filtered out by the message bus (such as `dbus-daemon`).

Rework the arithmetic to use checked arithmetic functions into a
`size_t` (largely as suggested by Simon McVittie), and add some unit
tests. Simply doing the arithmetic in the `gssize` domain would not fix
the issue on 32-bit systems.

Based on a report by Koda Reef, albeit reverse engineered as the report
did not contain a proof of concept of the vulnerability.

[smcv: Backport to 2.84.x by adding <stdint.h>]		 Philip Withnall <pwithnall@gnome.org> yes upstream backport, 2.88.1, commit:e28262f16979f3a2f5293233e5dae102cb47d61c 2026-04-20
gdbusauthmechanismsha1-Validate-cookie-context.patch gdbusauthmechanismsha1: Validate cookie context
Without validation, the server could send a malicious context which
contains path traversal characters, allowing it to exfiltrate a SHA-1
hashed copy of arbitrary data from the client’s file system.

To exploit this successfully would require the client to choose to
connect peer-to-peer to a malicious D-Bus server and to choose the SHA-1
authentication mechanism in preference to all the other mechanisms. This
is vanishingly unlikely.		 Philip Withnall <pwithnall@gnome.org> yes upstream upstream, 2.88.1, commit:db9c8fae398b0c457e660ce63dd5afec8993046a 2026-04-28
gdbusauthmechanismsha1-Improve-validation-of-cookie-ID.patch gdbusauthmechanismsha1: Improve validation of cookie ID
The D-Bus specification says the cookie ID has to be non-negative, but
we weren’t checking that (or checking that it was non-empty).

[smcv: Backport to 2.84.x by adding <stdint.h>]		 Philip Withnall <pwithnall@gnome.org> no backport, 2.88.1, commit:c0531125344bb25fd66ffb7435ed6c285de09aeb 2026-04-28
gdbusauthmechanism-Expose-client-reject-reason-as-a-new-v.patch gdbusauthmechanism: Expose client reject reason as a new vfunc
We can do this because `gdbusauthmechanism.h` is a private header.

Hook it up to the existing `reject_reason` code in each
`GDBusAuthMechanism` implementation, as all three implementations
currently intermingle reject reasons from the server and client code, so
there would currently be no benefit to having a separate server and
client implementation of `*_get_reject_reason()`.

This new private API will be used in a new unit test in the following
commit.		 Philip Withnall <pwithnall@gnome.org> no upstream, 2.88.1, commit:060aea67de7517d531b8fe2cdc07aa1a00ddeb22 2026-04-28
tests-Add-a-unit-test-for-GDBusAuthMechanismSha1-cookie-c.patch tests: Add a unit test for GDBusAuthMechanismSha1 cookie context parsing

This checks for regressions in the fixes from the previous few commits.		 Philip Withnall <pwithnall@gnome.org> yes upstream upstream, 2.88.1, commit:0919301962291a712067ee0c5d273cc392f33277 2026-04-28
gdbusauth-Limit-length-of-lines-read-from-client.patch gdbusauth: Limit length of lines read from client
The client isn’t trusted at this point, and there was previously nothing
limiting how long a line `GDBusAuth` would read. So an untrusted client
could exhaust the server’s memory by sending anything except `\r\n`.

Fix that by applying a reasonably length limit when reading a line, and
add a unit test.

Spotted by Gitee Codepecker Lab.		 Philip Withnall <pwithnall@gnome.org> yes debian upstream upstream, 2.88.3, commit:4235f7b42ba51d6fdb4abd7c4276031802f39834 2026-07-04
gdbusintrospection-Add-some-assertions-before-array-deref.patch gdbusintrospection: Add some assertions before array dereferences
The state handling inside the D-Bus introspection XML parser is
complicated, and it’s possible that these dereferences of the
`len - 1`th element might get reached when the array is empty.

Make failures like that more debuggable by adding an assertion on the
length beforehand.		 Philip Withnall <pwithnall@gnome.org> yes debian upstream upstream, 2.89.0, commit:656ad4582cb1d7a7fa8bafe3ce8aec6aa3c17da0 2026-04-16
tests-Improve-D-Bus-introspection-test-paths.patch tests: Improve D-Bus introspection test paths
This makes them more consistent with how test paths are meant to be
used.		 Philip Withnall <pwithnall@gnome.org> yes debian upstream upstream, 2.89.0, commit:7b276f05f66cc0df609ba68f76b8a8f4cd5297cb 2026-04-16
gdbusintrospection-Fix-XML-parser-state-handling-for-node.patch gdbusintrospection: Fix XML parser state handling for <node> element nesting

The check for whether a `<node>` element in D-Bus introspection XML was
nested correctly was broken. `<node>` elements can only be at the top
level, or nested immediately within another `<node>` element.

Fix the check and add some unit tests for it.

Spotted by linhlhq as #YWH-PGM9867-204. The fix is mine, and the unit test
uses example XML strings adapted from their report.		 Philip Withnall <pwithnall@gnome.org> yes debian upstream upstream, 2.89.0, commit:c9da977c178fbfc0e4caf99f9fdf5dc433d6fcc2 2026-04-16
fuzzing-Add-a-fuzz-test-for-g_dbus_node_info_new_for_xml.patch fuzzing: Add a fuzz test for g_dbus_node_info_new_for_xml() Philip Withnall <pwithnall@gnome.org> yes debian upstream upstream, 2.89.0, commit:4b3e3b6b69ddbca73a888c53bd98ef6916a84490 2026-04-19
CVE-2026-16118/xdgmime-Check-if-caches-are-set-before-dumping-them.patch xdgmime: Check if caches are set before dumping them
This fixes a test failure when smoketesting the `fuzz_dump` test on a
system where no xdgmime caches exist anywhere. The cache file generated
by splitting README (for the smoketest) obviously isn’t valid.		 Philip Withnall <pwithnall@gnome.org> no upstream, 2.89.4, commit:4ef012af942d517b84fac2d25c9031016818bb3d 2026-07-16
CVE-2026-16118/Fix-CVE-2026-16118-heap-buffer-overflow-in-xdgmimemagic.c.patch Fix CVE-2026-16118: heap-buffer-overflow in xdgmimemagic.c
Fix out-of-bounds write in the byte-swap routine of
_xdg_mime_magic_parse_magic_line(). On little-endian systems, the
write side of the swap casts the base pointer to a wider type before
adding the byte offset, causing pointer arithmetic to scale by
sizeof(type) instead of 1. With value_length=4 and word_size=2, the
loop writes 2 bytes past the allocated matchlet->value buffer at i=2.

Parenthesize (ptr + i) before the cast so both the read and write
sides use byte offsets.		 Kashyap Ekbote <kashyap.ekbote@gmail.com> yes debian upstream upstream, 2.89.4, commit:ca75aff83af9875ea2ad2bfbe48a85dfd99c2ce5 2026-08-05

All known versions for source package 'glib2.0'

Links