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.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #2121
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.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #2121
This reduces a few duplicate calls to `g_variant_type_info_query()` and
explains why they’re needed.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #2121
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.
Fixes: #2121
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.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #2121
Further to commit bcd364afef984da894045, fix the types accepted by the
`g_str_equal()` macro for C++ too. C++ is more restrictive about
const-correctness.
Add unit tests.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #2820
The new macro form of `g_str_equal()` had stricter type checking than
the original function form. That would be nice, except it causes new
compiler warnings in third party projects, which counts as an API break
for us, so unfortunately we can’t do it.
Add some tests to prevent regressions on this again.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #2809
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.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #2782
oss-fuzz#20177
oss-fuzz#49462
Backport !3029 “Revert "Handling collision between standard i/o file descriptors and newly created ones" ” to glib-2-74
See merge request GNOME/glib!3039
Now that we know it's a bad idea to avoid the standard io fd range
when getting pipe fds for g_unix_open_pipe, we should test to make sure
we don't inadvertently try to do it again.
This commit adds that test.
g_unix_open_pipe tries to avoid the standard io fd range
when getting pipe fds. This turns out to be a bad idea because
certain buggy programs rely on it using that range.
This reverts commit d9ba6150909818beb05573f54f26232063492c5b
Closes: #2795Reopens: #16
In g_proxy_resolver_lookup_async() we have some error validation that
detects invalid URIs and directly returns an error, bypassing the
interface's lookup_async() function. This is great, but when the
interface's lookup_finish() function gets called later, it may assert
that the source tag of the GTask matches the interface's lookup_async()
function, which will not be the case.
As suggested by Philip, we need to check for this situation in
g_proxy_resolver_lookup_finish() and avoid calling into the interface
here if we did the same in g_proxy_resolver_lookup_async(). This can be
done by checking the source tag.
I added a few new tests to check the invalid URI "asdf" used in the
issue report. The final case, using async GProxyResolver directly,
checks for this bug.
Fixes#2799
It’s entirely possible that `g_file_read_link()` will return a relative
path. Mention that in the documentation, and include a short example of
how to make the path absolute for further computation.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
The changes in 6265b2e6f70d6f0ec4d16adcdc5f7c53aecf0da4 to reject weird
`/etc/localtime` configurations where `/etc/localtime` links to another
symlink did not consider the case where the target of `/etc/localtime`
is a *relative* path. They only considered the case where the target is
absolute.
Relative paths are permissible in all symlinks. On my Fedora 36 system,
`/etc/localtime`’s target is `../usr/share/zoneinfo/Europe/London`.
Fix the check for toolbx by resolving relative paths before calling
`g_lstat()` on them.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
g_close() now is async-signal-safe, as long as we don't request a GError
and pass a valid file descriptor.
Update "gspawn.c" to drop its safe_close() function and use
g_close() instead.
g_close() does something useful. It is not trivial to get EINTR handling of
close() right, in a portable manner. g_close() abstracts this.
We should allow glib users to use the function even in async-signal-safe
contexts, at least if the user heeds the caveat about GError and take care
not to fail assertions.
Backport 2.74: Modified to drop documentation changes to g_close() which
document its new async-signal-safe guarantees. They are not public
guarantees until 2.76. Also modified to include moving the code to
ignore `EINTR` from commit d5dc7d266f2b8d0f7d.
When collecting varargs, ignore the NOCOPY_CONTENTS
flag for variants. That is what our docs advice for
refcounted types, and it fixes a regression that
was inadvertendly introduced when we stopped doing
some extra GValue copies.
Includes a test case by Philip Withnall.
Fixes: #2774
This reverts commit 0ffe86a1f7e215e4561c3b9f1d03c3cd638ed00f.
This was intended to land for the 2.75.x unstable series, and not in the
2.74.x stable series.
Fixes: #2788
This reverts commit dd1f4f709ea8cad1a1d6184ee0883be128fb81d8.
which caused a regression on big-endian architectures (all doubles would
hash to zero).
Partially resolves#2787
Signed-off-by: Simon McVittie <smcv@collabora.com>
This reverts commit c1af4b2b886bd77d6d8857cf3f677edbc0d34a61,
which caused a regression on big-endian architectures (all 64-bit
integers would hash to zero).
Partially resolves#2787
Signed-off-by: Simon McVittie <smcv@collabora.com>
This reverts commit e02db8ea22d545749ecaf3be9d342cc565bc143a.
We can't guarantee a lack of hash collisions if we go back to the 2.74.0
hashing implementation.
Signed-off-by: Simon McVittie <smcv@collabora.com>
