| Patch | Description | Author | Forwarded | Bugs | Origin | Last update |
|---|---|---|---|---|---|---|
| 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 | |
| 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 | ||
| 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/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-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). [Backport to 2.66.x: fix minor conflicts] |
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/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 | |
| Update-Croatian-translation.patch | Update Croatian translation | =?utf-8?q?Goran_Vidovi=C4=87?= <trebelnik2@gmail.com> | no | upstream, 2.66.9, commit:284b7eb7f202fe6fa25cae2fb56437d8abf70929 | 2021-10-27 | |
| gvariant-Clarify-operator-precedence.patch | gvariant: Clarify operator precedence This doesn’t change the behaviour of the code, but should squash some compiler/static analysis warnings about ‘are you sure you got the precedence right here?’. Coverity CID: #1159470 |
Philip Withnall <pwithnall@endlessos.org> | no | upstream, 2.67.2, commit:d5778ec4790c88b69ee2235922186437e9d73827 | 2020-12-08 | |
| Explain-magic-literals-in-G_VARIANT_-_INIT.patch | Explain magic literals in G_VARIANT_*_INIT | Alexander Klauer <alexander.klauer@googlemail.com> | no | upstream, 2.67.2, commit:bc2ca9df20818621309595a67101c504c1d10e6c | 2022-03-04 | |
| Fix-non-initialized-variable-in-glib-gvariant-parser.c.patch | Fix non-initialized variable in glib/gvariant-parser.c | Loic Le Page <llepage@fluendo.com> | no | upstream, 2.71.3, commit:28fa4325a45d55f1cf6d03509da7a123bf2a4c72 | 2022-01-19 | |
| gvariant-serialiser-Prevent-unbounded-recursion-in-is_nor.patch | gvariant-serialiser: Prevent unbounded recursion in is_normal() This fixes a bug in 7c4e6e9fbe473de0401c778c6b0c4aad27d5145a. The original approach in that commit accidentally only checked the depth at the leaf nodes in the variant tree, whereas actually the depth should be checked before recursing to avoid stack overflow. It neglected to consider that `g_variant_serialised_is_normal()` would be recursed into by some of the `DISPATCH(_is_normal)` cases. When that happened, the depth check was after the recursion so couldn’t prevent a stack overflow. |
Sebastian Wilhelmi <wilhelmi@google.com> | yes | upstream | upstream, 2.71.1, commit:77233f6f0779fe0c1cb48861d7deded4ae413567 | 2022-01-06 |
| gvariant-Fix-memory-leak-on-a-TYPE_CHECK-failure.patch | gvariant: Fix memory leak on a TYPE_CHECK failure | Egor Bychin <e.bychin@drweb.com> | no | upstream, 2.71.0, commit:05dffc1a7f562e9c8c6c21b67f99204f7a7b4e27 | 2021-10-11 | |
| gvariant-Fix-pointers-being-dereferenced-despite-NULL-che.patch | gvariant: Fix pointers being dereferenced despite NULL checks | Egor Bychin <e.bychin@drweb.com> | no | upstream, 2.71.0, commit:7f6ce4d8d234996b523b71abef139f1c80c88254 | 2021-10-11 | |
| Do-not-use-ensure_valid_-call-in-g_return_-macro.patch | Do not use ensure_valid_* call in g_return_* macro Replace all instances of ensure_valid_builder or ensure_valid_dict calls used as arguments to the g_return_if_fail or g_return_value_if_fail macros with otherwise equivalent code that always calls these functions, thus ensuring their side effects always apply. This commit does not change any external or private interfaces. |
Alexander Klauer <alexander.klauer@googlemail.com> | yes | upstream | upstream, 2.71.3, commit:340bc1ca799713da6d59eddf8611cfa62040c973 | 2022-03-04 |
| gvariant-Factor-out-type-check.patch | gvariant: Factor out type check This will help static analysers, similarly to with the previous commit. This introduces no functional changes. |
Philip Withnall <pwithnall@endlessos.org> | no | upstream, 2.73.0, commit:e0fe616dbc45ebf5270e788b3b344d04a1157a70 | 2022-05-10 | |
| gvariant-Zero-initialise-GVariantBuilder-children-under-s.patch | gvariant: Zero-initialise GVariantBuilder children under static analysis scan-build can’t link the types used in `g_variant_builder_init()` with the (same) types used in `g_variant_builder_end()`, so ends up assuming that the children have not been initialised. At runtime, this is prevented by the precondition checks on `GVSB()->offset` in `g_variant_builder_end()`. scan-build doesn’t notice that though. Avoid a scan-build warning by zero-initialising the children array when running static analysis. Doing this unconditionally would be an unnecessary performance hit. |
Philip Withnall <pwithnall@endlessos.org> | no | upstream, 2.73.1, commit:504727c31750bbd88e375011e5596e06a4b2694a | 2022-06-07 | |
| 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. [Backport to 2.66.x: fix minor conflicts] |
Simon McVittie <smcv@collabora.com> | no | upstream, https://gitlab.gnome.org/GNOME/glib/-/issues/3268 | 2024-05-01 | |
| gvariant-parser-Reject-deeply-nested-typedecls-in-text-fo.patch | gvariant-parser: Reject deeply-nested typedecls in text form variants Return `G_VARIANT_PARSE_ERROR_RECURSION` from `g_variant_parse()` if a typedecl is found within a text-form variant which would cause any part of the variant to exceed the maximum allowed recursion/nesting depth. This fixes an oversight when `G_VARIANT_MAX_RECURSION_DEPTH` was implemented, which allowed typedecls to effectively multiply the size of an array if `g_variant_parse()` was parsing a text-form variant without a top-level concrete type specified. |
Philip Withnall <pwithnall@endlessos.org> | yes | upstream | upstream, 2.74.1, commit:777606419d943be6568e823b29f2d6e6b98b60af | 2022-10-18 |
| gvariant-parser-Speed-up-maybe_wrapper-by-an-order-of-mag.patch | gvariant-parser: Speed up maybe_wrapper() by an order of magnitude This further helps with the potential denial of service problem in issue #2782 / oss-fuzz#49462 / oss-fuzz#20177. Instead of allocating a new `GVariant` for each nesting level of maybe-types, allocate a single `GVariant` and give it the fully-nested maybe type as its type. This has to be done in serialised form. This prevents attackers from triggering O(size of container × typedecl depth) allocations. This is a follow up to commit 3e313438f1900a620485ba88aad64c4e857f6ad1, and includes a test. |
Philip Withnall <pwithnall@endlessos.org> | yes | upstream | upstream, 2.74.2, commit:64c2f5f3bb339471278f560f5597ed35d65427b9 | 2022-11-07 |
| gvariant-core-Consolidate-construction-of-GVariantSeriali.patch | gvariant-core: Consolidate construction of `GVariantSerialised` So I only need to change it in one place. This introduces no functional changes. |
William Manley <will@stb-tester.com> | yes | upstream | upstream, 2.74.4, commit:590f7a6b76b5a3695aa562c9c3ab244433b6624b | 2020-06-23 |
| gvariant-serialiser-Factor-out-functions-for-dealing-with.patch | gvariant-serialiser: Factor out functions for dealing with framing offsets This introduces no functional changes. |
William Manley <will@stb-tester.com> | yes | upstream | upstream, 2.74.4, commit:f8f5d8eefa06008aa8fe684069193dc3b1ae1b58 | 2020-06-25 |
| gvariant-Zero-initialise-various-GVariantSerialised-objec.patch | gvariant: Zero-initialise various GVariantSerialised objects The following few commits will add a couple of new fields to `GVariantSerialised`, and they should be zero-filled by default. Try and pre-empt that a bit by zero-filling `GVariantSerialised` by default in a few places. |
Philip Withnall <pwithnall@endlessos.org> | yes | upstream | upstream, 2.74.4, commit:5c27f22aff636766fbc5e49927fd28213629e840 | 2022-10-25 |
| gvariant-Don-t-allow-child-elements-to-overlap-with-each-.patch | =?utf-8?q?gvariant=3A_Don=E2=80=99t_allow_child_elements_to_overla?= =?utf-8?q?p_with_each_other?= If different elements of a variable sized array can overlap with each other then we can cause a `GVariant` to normalise to a much larger type. This commit changes the behaviour of `GVariant` with non-normal form data. If an invalid frame offset is found all subsequent elements are given their default value. When retrieving an element at index `n` we scan the frame offsets up to index `n` and if they are not in order we return an element with the default value for that type. This guarantees that elements don't overlap with each other. We remember the offset we've scanned up to so we don't need to repeat this work on subsequent accesses. We skip these checks for trusted data. Unfortunately this makes random access of untrusted data O(n) — at least on first access. It doesn't affect the algorithmic complexity of accessing elements in order, such as when using the `GVariantIter` interface. Also: the cost of validation will be amortised as the `GVariant` instance is continued to be used. I've implemented this with 4 different functions, 1 for each element size, rather than looping calling `gvs_read_unaligned_le` in the hope that the compiler will find it easy to optimise and should produce fairly tight code. |
William Manley <will@stb-tester.com> | yes | upstream | upstream, 2.74.4, commit:c8067857f7c8fb369ecb30bb534b018b2e2b8f87 | 2020-06-29 |
| gvariant-serialiser-Factor-out-code-to-get-bounds-of-a-tu.patch | gvariant-serialiser: Factor out code to get bounds of a tuple member This introduces no functional changes. |
Philip Withnall <pwithnall@endlessos.org> | yes | upstream | upstream, 2.74.4, commit:66e7c10aa1ec3102c49186f83671a5f0461ffbc0 | 2022-01-07 |
| gvariant-serialiser-Rework-child-size-calculation.patch | gvariant-serialiser: Rework child size calculation This reduces a few duplicate calls to `g_variant_type_info_query()` and explains why they’re needed. |
Philip Withnall <pwithnall@endlessos.org> | yes | upstream | upstream, 2.74.4, commit:a62a6b5d3e53b30a4628db2a077ab9ed03605748 | 2022-01-07 |
| gvariant-Don-t-allow-child-elements-of-a-tuple-to-overlap.patch | =?utf-8?q?gvariant=3A_Don=E2=80=99t_allow_child_elements_of_a_tupl?= =?utf-8?q?e_to_overlap_each_other?= This is similar to the earlier commit which prevents child elements of a variable-sized array from overlapping each other, but this time for tuples. It is based heavily on ideas by William Manley. Tuples are slightly different from variable-sized arrays in that they contain a mixture of fixed and variable sized elements. All but one of the variable sized elements have an entry in the frame offsets table. This means that if we were to just check the ordering of the frame offsets table, the variable sized elements could still overlap interleaving fixed sized elements, which would be bad. Therefore we have to check the elements rather than the frame offsets. The logic of checking the elements up to the index currently being requested, and caching the result in `ordered_offsets_up_to`, means that the algorithmic cost implications are the same for this commit as for variable-sized arrays: an O(N) cost for these checks is amortised out over N accesses to O(1) per access. |
Philip Withnall <pwithnall@endlessos.org> | yes | upstream | upstream, 2.74.4, commit:2d55b3b74b1bc256e91a9d0d59120570376e6acc | 2022-01-07 |
| gvariant-Track-checked-and-ordered-offsets-independently.patch | gvariant: Track checked and ordered offsets independently The past few commits introduced the concept of known-good offsets in the offset table (which is used for variable-width arrays and tuples). Good offsets are ones which are non-overlapping with all the previous offsets in the table. If a bad offset is encountered when indexing into the array or tuple, the cached known-good offset index will not be increased. In this way, all child variants at and beyond the first bad offset can be returned as default values rather than dereferencing potentially invalid data. In this case, there was no information about the fact that the indexes between the highest known-good index and the requested one had been checked already. That could lead to a pathological case where an offset table with an invalid first offset is repeatedly checked in full when trying to access higher-indexed children. Avoid that by storing the index of the highest checked offset in the table, as well as the index of the highest good/ordered offset. |
Philip Withnall <pwithnall@endlessos.org> | yes | upstream | upstream, 2.74.4, commit:a6cb880af0a0932493ba096f01990e694e2c5b72 | 2022-10-25 |
| tests-Add-another-test-for-overlapping-offsets-in-GVarian.patch | tests: Add another test for overlapping offsets in GVariant | Philip Withnall <withnall@endlessm.com> | yes | upstream | upstream, 2.74.4, commit:8c1a7815e7e6695c120cdedff48395c1222af6d1 | 2020-06-12 |
| tests-Disable-some-random-instance-tests-of-GVariants.patch | tests: Disable some random instance tests of GVariants Building a `GVariant` using entirely random data may result in a non-normally-formed `GVariant`. It’s always possible to read these `GVariant`s, but the API might return default values for some or all of their components. In particular, this can easily happen when randomly generating the offset tables for non-fixed-width container types. If it does happen, bytewise comparison of the parsed `GVariant` with the original bytes will not always match. So skip those checks. |
Philip Withnall <pwithnall@endlessos.org> | yes | upstream | upstream, 2.74.4, commit:019505a7ccc32d0afa06e104dc0ac2e63e6f7189 | 2022-10-24 |
| gvariant-Clarify-the-docs-for-g_variant_get_normal_form.patch | gvariant: Clarify the docs for g_variant_get_normal_form() Document how non-normal parts of the `GVariant` are handled. |
Philip Withnall <pwithnall@endlessos.org> | yes | upstream | upstream, 2.74.4, commit:9d2a142807806212a23436d0332b0209733810f2 | 2022-10-24 |
| gvariant-Port-g_variant_deep_copy-to-count-its-iterations.patch | gvariant: Port g_variant_deep_copy() to count its iterations directly This is equivalent to what `GVariantIter` does, but it means that `g_variant_deep_copy()` is making its own `g_variant_get_child_value()` calls. This will be useful in an upcoming commit, where those child values will be inspected a little more deeply. |
Philip Withnall <pwithnall@endlessos.org> | yes | upstream | upstream, 2.74.4, commit:b0ccb1616688290088e49dea2dc0d7fe723136e4 | 2022-10-24 |
| gvariant-Add-internal-g_variant_maybe_get_child_value.patch | gvariant: Add internal g_variant_maybe_get_child_value() This will be used in a following commit. |
Philip Withnall <pwithnall@endlessos.org> | yes | upstream | upstream, 2.74.4, commit:1770e255ae6cc3f0bf5312322432bbc6524a3632 | 2022-10-25 |
| Exclude-g_variant_maybe_get_child_value-from-API-document.patch | Exclude g_variant_maybe_get_child_value from API documentation This is an internal function, and not part of the public API/ABI. GLib 2.66.x fails tests if such functions have a "Since" annotation pointing to a future branch. |
Simon McVittie <smcv@debian.org> | not-needed | 2023-09-30 | ||
| gvariant-Cut-allocs-of-default-values-for-children-of-non.patch | gvariant: Cut allocs of default values for children of non-normal arrays This improves a slow case in `g_variant_get_normal_form()` where allocating many identical default values for the children of a variable-sized array which has a malformed offset table would take a lot of time. The fix is to make all child values after the first invalid one be references to the default value emitted for the first invalid one, rather than identical new `GVariant`s. In particular, this fixes a case where an attacker could create an array of length L of very large tuples of size T each, corrupt the offset table so they don’t have to specify the array content, and then induce `g_variant_get_normal_form()` into allocating L×T default values from an input which is significantly smaller than L×T in length. A pre-existing workaround for this issue is for code to call `g_variant_is_normal_form()` before calling `g_variant_get_normal_form()`, and to skip the latter call if the former returns false. This commit improves the behaviour in the case that `g_variant_get_normal_form()` is called anyway. This fix changes the time to run the `fuzz_variant_binary` test on the testcase from oss-fuzz#19777 from >60s (before being terminated) with 2.3GB of memory usage and 580k page faults; to 32s, 8.3MB of memory usage and 1500 page faults (as measured by `time -v`). |
Philip Withnall <pwithnall@endlessos.org> | yes | upstream | upstream, 2.74.4, commit:82fc15af4c84a2645343c51b18ab3528c51790ab | 2022-10-25 |
| gvariant-Fix-a-leak-of-a-GVariantTypeInfo-on-an-error-han.patch | gvariant: Fix a leak of a GVariantTypeInfo on an error handling path | Philip Withnall <pwithnall@endlessos.org> | no | upstream, 2.74.4, commit:935f1c200789c76ad5b51b1f403f611e3cc75318 | 2022-10-25 | |
| gvariant-serialiser-Check-offset-table-entry-size-is-mini.patch | gvariant-serialiser: Check offset table entry size is minimal The entries in an offset table (which is used for variable sized arrays and tuples containing variable sized members) are sized so that they can address every byte in the overall variant. The specification requires that for a variant to be in normal form, its offset table entries must be the minimum width such that they can address every byte in the variant. That minimality requirement was not checked in `g_variant_is_normal_form()`, leading to two different byte arrays being interpreted as the normal form of a given variant tree. That kind of confusion could potentially be exploited, and is certainly a bug. Fix it by adding the necessary checks on offset table entry width, and unit tests. Spotted by William Manley. |
Philip Withnall <pwithnall@endlessos.org> | yes | upstream | upstream, 2.74.4, commit:f1dfc5d0c5c0486b5fccb2ceddf1db1162c7033c | 2022-10-27 |
| gvariant-Fix-g_variant_byteswap-returning-non-normal-data.patch | gvariant: Fix g_variant_byteswap() returning non-normal data sometimes If `g_variant_byteswap()` was called on a non-normal variant of a type which doesn’t need byteswapping, it would return a non-normal output. That contradicts the documentation, which says that the return value is always in normal form. Fix the code so it matches the documentation. Includes a unit test. |
Philip Withnall <pwithnall@endlessos.org> | yes | upstream | upstream, 2.74.4, commit:781f05a22ef11d8a2177b4e9078978decec36dd0 | 2022-10-27 |
| gvariant-Allow-g_variant_byteswap-to-operate-on-tree-form.patch | gvariant: Allow g_variant_byteswap() to operate on tree-form variants This avoids needing to always serialise a variant before byteswapping it. With variants in non-normal forms, serialisation can result in a large increase in size of the variant, and a lot of allocations for leaf `GVariant`s. This can lead to a denial of service attack. Avoid that by changing byteswapping so that it happens on the tree form of the variant if the input is in non-normal form. If the input is in normal form (either serialised or in tree form), continue using the existing code as byteswapping an already-serialised normal variant is about 3× faster than byteswapping on the equivalent tree form. The existing unit tests cover byteswapping well, but need some adaptation so that they operate on tree form variants too. I considered dropping the serialised byteswapping code and doing all byteswapping on tree-form variants, as that would make maintenance simpler (avoiding having two parallel implementations of byteswapping). However, most inputs to `g_variant_byteswap()` are likely to be serialised variants (coming from a byte array of input from some foreign source) and most of them are going to be in normal form (as corruption and malicious action are rare). So getting rid of the serialised byteswapping code would impose quite a performance penalty on the common case. |
Philip Withnall <pwithnall@endlessos.org> | yes | upstream | upstream, 2.74.4, commit:7d7efce1d9c379fdd7d2ff58caea88f8806fdd2e | 2022-10-27 |
| gvariant-serialiser-Convert-endianness-of-offsets.patch | gvariant-serialiser: Convert endianness of offsets The array of offsets is little-endian, even on big-endian architectures like s390x. |
Simon McVittie <smcv@collabora.com> | yes | upstream | upstream, 2.74.4, commit:dc16dffed0480d0c8cdd6a05ede68263fc8723a9 | 2022-12-15 |
| gvariant-Check-offset-table-doesn-t-fall-outside-variant-.patch | =?utf-8?q?gvariant=3A_Check_offset_table_doesn=E2=80=99t_fall_outs?= =?utf-8?q?ide_variant_bounds?= When dereferencing the first entry in the offset table for a tuple, check that it doesn’t fall outside the bounds of the variant first. This prevents an out-of-bounds read from some non-normal tuples. This bug was introduced in commit 73d0aa81c2575a5c9ae77d. Includes a unit test, although the test will likely only catch the original bug if run with asan enabled. |
Philip Withnall <pwithnall@endlessos.org> | yes | upstream | upstream, 2.74.4, commit:bf008669f26f70426ca30ee8cdcbd48e41a74718 | 2022-12-15 |
| gvariant-Propagate-trust-when-getting-a-child-of-a-serial.patch | gvariant: Propagate trust when getting a child of a serialised variant If a variant is trusted, that means all its children are trusted, so ensure that their checked offsets are set as such. This allows a lot of the offset table checks to be avoided when getting children from trusted serialised tuples, which speeds things up. No unit test is included because this is just a performance fix. If there are other slownesses, or regressions, in serialised `GVariant` performance, the fuzzing setup will catch them like it did this one. This change does reduce the time to run the oss-fuzz reproducer from 80s to about 0.7s on my machine. |
Philip Withnall <pwithnall@endlessos.org> | yes | upstream | upstream, 2.74.4, commit:4d0bed8c4690f7a2692474ef6a570bd99ef45ef1 | 2022-12-15 |
| gvariant-Factor-out-some-common-calls-to-g_variant_get_ty.patch | gvariant: Factor out some common calls to g_variant_get_type_string() When printing a `GVariant`. This introduces no functional changes, but should speed things up a little bit when printing out arrays. |
Philip Withnall <pwithnall@endlessos.org> | no | upstream, 2.74.5, commit:f068347b1419213be20e3647f5d4f1d505bdcba4 | 2022-12-29 | |
| gvariant-Optimise-g_variant_print-for-nested-maybes.patch | gvariant: Optimise g_variant_print() for nested maybes As with commit 9ae59bd647882bcb33103331255a5149d2fb90d2, deeply nested maybes in an array can be exploited by a malicious caller to cause a geometric increase in processing time and number of `GVariant` instances handled by the `g_variant_print()` code. Optimise this by skipping recursing through most of the chain of maybes, thus avoiding all the setup checks in each recursive call. |
Philip Withnall <pwithnall@endlessos.org> | no | upstream, 2.74.5, commit:53702d68c4ee7b939a725ec4a5d707a2bdead1e9 | 2022-12-29 | |
| gvariant-Remove-redundant-g_variant_serialised_n_children.patch | gvariant: Remove redundant g_variant_serialised_n_children() calls These functions were previously calling `g_variant_serialised_n_children()` twice just to validate the input, in the case that the input was a serialised variant. That’s not necessary, and checking the number of children in a serialised variant is not necessarily cheap. Move the checks around so that the number of children is only checked once on each code path. This doesn’t introduce any functional changes. |
Philip Withnall <pwithnall@endlessos.org> | no | upstream, 2.74.5, commit:8373f328bd1e996a1521eed3f962af873cfa14a0 | 2022-12-29 | |
| gvariant-Remove-some-unnecessary-type-assertions-on-a-hot.patch | gvariant: Remove some unnecessary type assertions on a hot path While checking the validity of a `GVariantTypeInfo` is good, this code path is very hot, and I’ve never seen these assertions catch a bug in practice. Lean more towards the performance side of the performance/correctness tradeoff in this case, by removing the assertions here. They remain in place in a number of other `GVariantTypeInfo` code paths, so invalid `GVariantTypeInfo` pointers should hopefully still be caught quickly. |
Philip Withnall <pwithnall@endlessos.org> | no | upstream, 2.74.5, commit:ab8cdb07dece52f0226a1d0346157b6f172ed1ba | 2022-12-29 | |
| glib-tests-fileutils-Make-more-use-of-g_assert_no_errno.patch | glib/tests/fileutils: Make more use of g_assert_no_errno() | Simon McVittie <smcv@collabora.com> | yes | 2020-10-28 | ||
| glib-tests-fileutils-Fix-expectations-when-running-as-roo.patch | glib/tests/fileutils: Fix expectations when running as root This test asserts that g_file_set_contents_full() will fail when used on a read-only file, but processes with CAP_DAC_OVERRIDE on Linux or uid 0 on traditional Unix can and do ignore DAC permissions. See also #2027, #2028. |
Simon McVittie <smcv@collabora.com> | yes | debian | 2020-10-28 | |
| glocalfileoutputstream-Tidy-up-error-handling.patch | glocalfileoutputstream: Tidy up error handling After the recent reworking of this code it was possible for `g_close()` to be called on `fd == -1`, which is invalid. It would have reported an error, were errors not ignored. So it was harmless, but still best to fix. Simplify the error handling by combining both error labels and checking the state of `fd` dynamically. Coverity CID: #1450834 |
Philip Withnall <pwithnall@endlessos.org> | no | upstream, 2.68.0, commit:c4b4fecaef5fa6eac63569513511ba6f8674548a | 2021-03-16 | |
| 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/taptestrunner-Stop-looking-like-an-executable-script.patch | taptestrunner: Stop looking like an executable script This file is installed as non-executable but starts with the #! that indicates an executable script, causing warnings from Debian's Lintian tool. In fact it is imported as a Python module rather than being run as an executable, so there is no need for the #! line. |
Simon McVittie <smcv@debian.org> | no | 2019-10-30 | ||
| 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/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. [Backport to 2.66.x: fix minor conflicts] |
Simon McVittie <smcv@collabora.com> | no | upstream, https://gitlab.gnome.org/GNOME/glib/-/issues/3268 | 2024-05-01 | |
| 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/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 |
| 0001-gsocks4aproxy-Fix-a-single-byte-buffer-overflow-in-c.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.) |
Michael Catanzaro <mcatanzaro@redhat.com> | no | 2024-09-19 |