| Patch | Description | Author | Forwarded | Bugs | Origin | Last update |
|---|---|---|---|---|---|---|
| gdbus-Never-buffer-reads-during-server-authentication.patch | 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. |
Marius Vollmer <mvollmer@redhat.com> | yes | upstream | https://gitlab.gnome.org/GNOME/glib/-/merge_requests/3300 | 2023-02-13 |
| gdbusinterfaceskeleton-Remove-an-unnecessary-helper-struc.patch | gdbusinterfaceskeleton: Remove an unnecessary helper struct member The `GDBusInterfaceSkeleton` is already stored as the source object of the `GTask` here, with a strong reference. Storing it again in the task’s data struct is redundant, and makes it look like the `GDBusInterfaceSkeleton` is being used without holding a strong reference. (There’s 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. |
Philip Withnall <pwithnall@endlessos.org> | yes | upstream | https://gitlab.gnome.org/GNOME/glib/-/merge_requests/3298 | 2023-02-22 |
| gdbusinterfaceskeleton-Fix-a-use-after-free-of-a-GDBusMet.patch | gdbusinterfaceskeleton: Fix a use-after-free of a GDBusMethodInvocation 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. |
Philip Withnall <pwithnall@endlessos.org> | yes | upstream | https://gitlab.gnome.org/GNOME/glib/-/merge_requests/3298 | 2023-02-22 |
| gdbusconnection-Make-GDBusMethodInvocation-transfer-a-bit.patch | 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. |
Philip Withnall <pwithnall@endlessos.org> | yes | upstream | https://gitlab.gnome.org/GNOME/glib/-/merge_requests/3298 | 2023-02-22 |
| gdbus-Fix-an-accidental-string-freeze-break.patch | 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. |
Philip Withnall <pwithnall@endlessos.org> | yes | upstream | https://gitlab.gnome.org/GNOME/glib/-/merge_requests/3303 | 2023-03-02 |
| tests-Skip-assert-msg-test.py-if-gdb-fails.patch | 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) |
Matt Turner <mattst88@gmail.com> | no | https://gitlab.gnome.org/GNOME/glib/-/merge_requests/3307 | 2023-03-02 | |
| tests-Don-t-rely-on-output-locale-of-sort-in-spawn-test.patch | =?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. |
Philip Withnall <pwithnall@endlessos.org> | yes | upstream | upstream, 2.75.0, commit:360fc4cda351705102e72e1eeb3c4385fa7fda62 | 2022-10-13 |
| 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 | |
| 0001-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 | |
| 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 | |
| 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/06_thread_test_ignore_prctl_fail.patch | Do not fail the /thread/thread4 test if prlimit() fails This happens on the Debian buildds. [smcv: Use g_test_skip()] |
Martin Pitt <martin.pitt@ubuntu.com> | invalid | 2012-06-26 | ||
| debian/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 | |
| debian/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 | ||
| debian/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 | |
| debian/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 | |
| debian/gmenumodel-test-Mark-as-flaky.patch | gmenumodel test: Mark as flaky This test has not had a great history of reliability. |
Simon McVittie <smcv@debian.org> | no | debian | 2019-07-26 | |
| debian/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 | |
| debian/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 | ||
| debian/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 | |
| debian/Add-extra-debug-to-memory-monitor-dbus-test.patch | 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. |
Simon McVittie <smcv@debian.org> | no | debian | 2021-10-24 | |
| debian/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 | ||
| debian/gdesktopappinfo-Recognize-gnome-console-as-a-terminal-app.patch | 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 |
Jeremy Bicha <jeremy.bicha@canonical.com> | no | 2022-03-23 | ||
| debian/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 | ||
| CVE-2024-34397/gdbusmessage-Cache-the-arg0-value.patch | gdbusmessage: Cache the arg0 value Technically we can’t rely on it being kept alive by the `message->body` pointer, unless we can guarantee that the `GVariant` is always serialised. That’s 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] (cherry picked from commit 10e9a917be7fb92b6b27837ef7a7f1d0be6095d5) |
Philip Withnall <pwithnall@gnome.org> | no | upstream, commit:https://gitlab.gnome.org/GNOME/glib/-/commit/10e9a917be7fb92b6b27837ef7a7f1d0be6095d5 | 2023-11-28 | |
| CVE-2024-34397/gdbusconnection-Make-a-backport-of-g_set_str-available.patch | 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. |
Simon McVittie <smcv@collabora.com> | no | upstream, https://gitlab.gnome.org/GNOME/glib/-/issues/3268 | 2024-05-01 | |
| CVE-2024-34397/tests-Add-a-data-driven-test-for-signal-subscriptions.patch | tests: Add a data-driven test for signal subscriptions This somewhat duplicates test_connection_signals(), but is easier to extend to cover different scenarios. Each scenario is tested three times: once with lower-level GDBusConnection APIs, once with the higher-level GDBusProxy (which cannot implement all of the subscription scenarios, so some message counts are lower), and once with both (to check that delivery of the same message to multiple destinations is handled appropriately). [Backported to glib-2-74, resolving conflicts in gio/tests/meson.build] |
Simon McVittie <smcv@collabora.com> | no | upstream, https://gitlab.gnome.org/GNOME/glib/-/issues/3268 | 2024-03-08 | |
| CVE-2024-34397/tests-Add-support-for-subscribing-to-signals-from-a-well-.patch | tests: Add support for subscribing to signals from a well-known name | Simon McVittie <smcv@collabora.com> | no | upstream, https://gitlab.gnome.org/GNOME/glib/-/issues/3268 | 2024-03-08 | |
| CVE-2024-34397/tests-Add-a-test-case-for-what-happens-if-a-unique-name-d.patch | 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. |
Simon McVittie <smcv@collabora.com> | no | upstream, https://gitlab.gnome.org/GNOME/glib/-/issues/3268 | 2024-03-08 | |
| CVE-2024-34397/tests-Add-test-coverage-for-signals-that-match-the-messag.patch | 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. |
Simon McVittie <smcv@collabora.com> | no | upstream, https://gitlab.gnome.org/GNOME/glib/-/issues/3268 | 2024-03-08 | |
| CVE-2024-34397/gdbusprivate-Add-symbolic-constants-for-the-message-bus-i.patch | gdbusprivate: Add symbolic constants for the message bus itself Using these is a bit more clearly correct than repeating them everywhere. To avoid excessive diffstat in a branch for a bug fix, I'm not immediately replacing all existing occurrences of the same literals with these names. The names of these constants are chosen to be consistent with libdbus, despite using somewhat outdated terminology (D-Bus now uses the term "well-known bus name" for what used to be called a service name, reserving the word "service" to mean specifically the programs that have .service files and participate in service activation). |
Simon McVittie <smcv@collabora.com> | no | upstream, https://gitlab.gnome.org/GNOME/glib/-/issues/3268 | 2024-03-14 | |
| CVE-2024-34397/gdbusconnection-Move-SignalData-SignalSubscriber-higher-u.patch | 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. |
Simon McVittie <smcv@collabora.com> | no | upstream, https://gitlab.gnome.org/GNOME/glib/-/issues/3268 | 2024-03-14 | |
| CVE-2024-34397/gdbusconnection-Factor-out-signal_data_new_take.patch | 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). |
Simon McVittie <smcv@collabora.com> | no | upstream, https://gitlab.gnome.org/GNOME/glib/-/issues/3268 | 2024-03-14 | |
| CVE-2024-34397/gdbusconnection-Factor-out-add_signal_data.patch | gdbusconnection: Factor out add_signal_data() No functional changes. |
Simon McVittie <smcv@collabora.com> | no | upstream, https://gitlab.gnome.org/GNOME/glib/-/issues/3268 | 2024-04-23 | |
| CVE-2024-34397/gdbusconnection-Factor-out-remove_signal_data_if_unused.patch | 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. |
Simon McVittie <smcv@collabora.com> | no | upstream, https://gitlab.gnome.org/GNOME/glib/-/issues/3268 | 2024-03-14 | |
| CVE-2024-34397/gdbusconnection-Stop-storing-sender_unique_name-in-Signal.patch | 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. |
Simon McVittie <smcv@collabora.com> | no | upstream, https://gitlab.gnome.org/GNOME/glib/-/issues/3268 | 2024-04-23 | |
| CVE-2024-34397/gdbus-Track-name-owners-for-signal-subscriptions.patch | 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] |
Simon McVittie <smcv@collabora.com> | no | upstream, https://gitlab.gnome.org/GNOME/glib/-/issues/3268 | 2024-05-01 | |
| CVE-2024-34397/gdbusconnection-Don-t-deliver-signals-if-the-sender-doesn.patch | 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. |
Simon McVittie <smcv@collabora.com> | no | upstream, https://gitlab.gnome.org/GNOME/glib/-/issues/3268 | 2024-03-14 | |
| CVE-2024-34397/tests-Add-a-test-for-matching-by-two-well-known-names.patch | 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. |
Simon McVittie <smcv@collabora.com> | no | upstream, https://gitlab.gnome.org/GNOME/glib/-/issues/3268 | 2024-03-08 | |
| CVE-2024-34397/tests-Add-a-test-for-signal-filtering-by-well-known-name.patch | tests: Add a test for signal filtering by well-known name The vulnerability reported as GNOME/glib#3268 can be characterized the GDBusConnection or the GDBusProxy, but in fact they are (in at least some scenarios). |
Simon McVittie <smcv@collabora.com> | no | upstream, https://gitlab.gnome.org/GNOME/glib/-/issues/3268 | 2024-03-08 | |
| CVE-2024-34397/tests-Ensure-that-unsubscribing-with-GetNameOwner-in-flig.patch | 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). |
Simon McVittie <smcv@collabora.com> | no | upstream, https://gitlab.gnome.org/GNOME/glib/-/issues/3268 | 2024-04-23 | |
| CVE-2024-34397/gdbus-proxy-test-Wait-before-asserting-name-owner-has-gon.patch | 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. |
Simon McVittie <smcv@debian.org> | no | 2024-05-06 | ||
| CVE-2024-34397/gdbusconnection-Allow-name-owners-to-have-the-syntax-of-a.patch | 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. |
Simon McVittie <smcv@debian.org> | yes | debian upstream | 2024-05-08 | |
| gdbusmessage-Clean-the-cached-arg0-when-setting-the-messa.patch | 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 |
=?utf-8?b?Ik1hcmNvIFRyZXZpc2FuIChUcmV2acOxbyki?= <mail@3v1n0.net> | no | debian | upstream, 2.80.3, commit:fe89e9f3cb6e0fd0dc2bd8a2d413799e1443cef1 | 2024-05-08 |
| gsocks4aproxy-Fix-a-single-byte-buffer-overflow-in-connec.patch | 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 |
Michael Catanzaro <mcatanzaro@redhat.com> | yes | debian upstream | upstream, 2.82.1, commit:ec0b708b981af77fef8e4bbb603cde4de4cd2e29 | 2024-09-19 |