If a path starts with more than two slashes, the `start` value was
previously incorrect:
1. As per the `g_path_skip_root()` call, `start` was set to point to
after the final initial slash. For a path with three initial
slashes, this is the character after the third slash.
2. The canonicalisation loop to find the first dir separator sets
`output` to point to the character after the first slash (and it
overwrites the first slash to be `G_DIR_SEPARATOR`).
3. At this point, with a string `///usr`, `output` points to the second
`/`; and `start` points to the `u`. This is incorrect, as `start`
should point to the starting character for output, as per the
original call to `g_path_skip_root()`.
4. For paths which subsequently include a `..`, this results in the
`output > start` check in the `..` loop below not skipping all the
characters of a preceding path component, which is then caught by
the `G_IS_DIR_SEPARATOR (output[-1])` assertion.
Fix this by resetting `start` to `output` after finding the final slash
to keep in the output, but before starting the main parsing loop.
Relatedly, split `start` into two variables: `after_root` and
`output_start`, since the variable actually has two roles in the two
parts of the function.
Includes a test.
This commit is heavily based on suggestions by Sebastian Wilhemi and
Sebastian Dröge.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
oss-fuzz#41563
Improve the performance of canonicalising filenames with many `..` or
`.` components, by modifying the path inline rather than calling
`memmove()`.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #2541
meson in git master now warns about a missing `check:` kwarg, and may
eventually change the default from false to true.
Take the opportunity to require `objcopy --help` to succeed -- it is
unlikely to fail, but if it does something insane happened.
We used to use a pipe for the dbus daemon stdout to read the defined
address, but that was already requiring a workaround to ensure that dbus
daemon children were then able to write to stdout.
However the current implementation is still causing troubles in some
cases in which the daemon is very verbose, leading to hangs when writing
to stdout.
As per this, just don't handle stdout ourself, but use instead a
specific pipe to get the address address. That can now be safely closed
once we've received the data we need.
This reverts commit d80adeaa96.
Fixes: #2537
This improves how we obtain the Windows release versions in
get_windows_version(), in turn g_get_os_info() for Windows 10/Server
2019 20H2 (2009) and later and Windows 11, by doing the following:
* Check the build number for non-server versions of Windows.
For Windows 11, the build number is 22000+, so we now correctly
indicate on Windows 11 that we are indeed running Windows 11.
* Check the DisplayVersion entry in the registry under
SOFTWARE\Microsoft\Windows NT\CurrentVersion if we obtained "2009"
from the ReleaseId entry, since DisplayVersion replaces ReleaseId
after Windows 10/Server 2019 20H2 (2009). This makes things more
clear for Windows releases after 20H2, where previously 20H2
and 21H1 were all identified as Windows 10 [Server] 2009.
This should fix issue #2443.
Unfortunately, we may well be likely to need to call RtlGetVersion() via
GetModuleHandle() + GetProcAddress(), so split out the call to RtlGetVersion()
into a private function of its own, so that we can reuse the same code in other
parts of GLib, so that we can:
* Determine better in a more fine-tuned way to determine whether we are on
Windows 10/11 and/or Server 2016/2019/2022, since we need to rely on the
build number.
* Just call RtlGetVersion() once, when needed, as that is all that is needed.
We could re-use the same function once to compare what we got when we
called RtlGetVersion() and do what is necessary there.
The code in `g_dbus_message_new_from_blob()` has now been fixed to
correctly error out on all truncated messages, so there’s no need for an
arbitrary programmer error if the input is too short to contain a valid
D-Bus message header.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #2528
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
Fix another variant of the previous commit, this time specific to the
idle callback of a method call on a subtree object, racing with
unregistration of that subtree.
In this case, the `process_subtree_vtable_message_in_idle_cb()` idle
callback already has a pointer to the right `ExportedSubtree` struct,
but again doesn’t have a strong reference to it.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #2400
If `g_dbus_connection_unregister_object()` (or `unregister_subtree()`)
was called from one thread, while an idle callback for a method call (or
a property get or set) was being invoked in another, it was possible for
the two to race after the idle callback had checked that the
object/subtree was registered, but before it had finished dereferencing
all the data related to that object/subtree.
Unregistering the object/subtree would immediately free the data,
leading the idle callback to cause a use-after-free error.
Fix that by giving the idle callback a strong reference to the data from
inside the locked section where it checks whether the object/subtree is
still registered.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #2400
This is needed for an upcoming change which decouples their lifecycle
from their presence in the `map_id_to_ei` and `map_id_to_es` hash
tables.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #2400
Move it further up the file, but make no changes to it. This will help
with a subsequent commit.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #2400
