This looks like a regression from commit 3356934db5, but prior to that
commit there was always an assertion failure when calling
`g_time_zone_new_offset()` with an offset which is too large (such as 44
hours), ever since the function was added in commit cf24867b93.
It would be ideal if we could return a `NULL` timezone to indicate the
error, but that’s not part of the API for `g_time_zone_new_offset()`, so
we have to go with the dated and not-ideal approach of returning the UTC
timezone and letting the caller figure it out.
Another potential approach would be to reduce the `offset` modulo 24
hours. This makes the error less easily detectable than if returning
UTC, though, and still returns an invalid result: `+44:00` is not the
same timezone as `+20:00` (it’s one day further ahead).
Add a unit test.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #2620
The output pointer must not go past the ending \0.
warning: HEAP[testglib.exe]:
warning: Heap block at 0000011EA35745A0 modified at 0000011EA35745BF past requested size of f
Fixes commit 9a30a495ec "gfileutils: Improve performance of g_canonicalize_filename()"
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
They are not allowed in the specification, and can lead to infinite
loops when parsing.
That’s a security issue if your application is accepting D-Bus messages
from untrusted peers (perhaps in a peer-to-peer connection). It’s not
exploitable when your application is connected to a bus (such as the
system or session buses), as the bus daemons (dbus-daemon or
dbus-broker) filter out such broken messages and don’t forward them.
Arrays of zero-length elements are disallowed in the D-Bus
specification: https://dbus.freedesktop.org/doc/dbus-specification.html#container-types
oss-fuzz#41428, #41435Fixes: #2557
This fixes a bug in 7c4e6e9fbe.
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.
Fixes: #2572
If a seccomp policy is set up incorrectly so that it returns `EPERM` for
`close_range()` rather than `ENOSYS` due to it not being recognised, no
error would previously be reported from GLib, but some file descriptors
wouldn’t be closed, and that would cause a hung zombie process. The
zombie process would be waiting for one half of a socket to be closed.
Fix that by correctly propagating errors from `close_range()` back to the
parent process so they can be reported correctly.
Distributions which aren’t yet carrying the Docker fix to correctly
return `ENOSYS` from unrecognised syscalls may want to temporarily carry
an additional patch to fall back to `safe_fdwalk()` if `close_range()`
fails with `EPERM`. This change will not be accepted upstream as `EPERM`
is not the right error for `close_range()` to be returning.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #2580
This code was skipping fsync on BTRFS because of an old guarantee about
the overwrite-by-rename behavior that no longer holds true. This has
been confirmed by the BTRFS developers to no longer be guaranteed since
Kernel 3.17 (August 2014), but it was guaranteed when this optimization
was first introduced in 2010.
This could result in empty files after crashes in applications using
g_file_set_contents(). Most prominently this might have been the cause
of dconf settings getting lost on BTRFS after crashes due to the
frequency with which such writes can happen in dconf.
See: https://gitlab.gnome.org/GNOME/dconf/-/issues/73
