Perform strict bounds checking when reading data from the D-Bus message,
and propagate errors to the callers.
Previously, truncated D-Bus messages could cause out-of-bounds reads.
This is a security issue, but one which is only exploitable when
communicating with an untrusted peer (who might send malicious
messages). Almost all D-Bus traffic is with a session or system bus,
where the dbus-daemon or dbus-broker is trusted, and is known to have
already rejected malformed (malicious) messages.
Accordingly, this is only exploitable with peer-to-peer D-Bus
conversations with an untrusted peer.
(Includes some minor cleanups from Philip Withnall.)
oss-fuzz#17408
Fixes: #2528
This introduces no functional changes; it only simplifies the code.
Instead of maintaining a separate pointer to the backend iff it’s a
`GDelayedSettingsBackend`, just test the `backend` pointer’s type.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #2426
Previously, the delay-apply status of the parent `GSettings` object
would be partially inherited: `settings->priv->backend` in the child
`GSettings` object would point to a `GDelayedSettingsBackend`, but
`settings->priv->delayed` would be `NULL`.
The expectation from https://bugzilla.gnome.org/show_bug.cgi?id=720891
was that `get_child()` would fully inherit delay-apply status.
So, ensure that `settings->priv->delayed` is correctly set to point to
the delayed backend when constructing any `GSettings`. Update the tests
to work again (presumably the inverted test was an oversight in the
original changes).
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #2426
`g_settings_reset()` changes the value of the setting to `NULL`;
`add_to_tree()` was not handling that correctly.
Add a unit test.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #2426
It is exactly the same wrap as the one in WrapDB but with a different
name. That fix error when multiple projects uses pcre and they don't
have the same wrap name:
meson.build:1:0: ERROR: Multiple wrap files provide 'libpcre' dependency: pcre.wrap and libpcre.wrap
Relax assertion about opened registry key as it may have been removed
in the meantime between enumeration and when opening, or (more likely)
we may not have the required permissions to open the some enumerated
keys (i.e. RegOpenKeyExW fails and returns ERROR_ACCESS_DENIED).
Fixes https://gitlab.com/inkscape/inbox/-/issues/5669
0.2 was just tagged, which includes a commit from 2018 that fixes a
meson warning which caused the project to fail to build on Windows with
--fatal-meson-warnings enabled.
(cherry picked from commit 9255f1b2a9)
The "recursive:" kwarg is available in the targeted minimum version of
meson, and is basically required if you want to not emit warnings and
maybe error with --fatal-meson-warnings.
The current default behavior is false, so explicitly opt in to that value.
None of these internal libraries use recursive objects anyway.
In commit c74d87e44038925baf37367ce124c027e225c11e we went a different
route, and upgraded the minimum meson version and dropped the TODO
workarounds in these files. But for a stable branch this is not
desirable.
MSVC supports AddressSanitizer as well via "/fsanitize=address" option,
but __lsan_ignore_object() equivalent feature is not supported.
Note that there's __declspec(no_sanitize_address) specifier which
provides a similar feature but that's not runtime behavior
so it's not directly applicable to g_ignore_leak() family.
See also https://docs.microsoft.com/en-us/cpp/sanitizers/asan-building?view=msvc-160
