When extracting a UTF-8 character to put in an error message on parse
failure, pass the remaining buffer length to utf8_str() to avoid it
running off the end of the input buffer. It previously assumed that the
buffer was nul-terminated, which was the case in all the tests until
now.
A following commit will add test coverage for this.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
When using GMarkup to parse a string, the string can be provided with an
explicit length specified, or with no length and a nul terminator
instead. Run all the GMarkup tests both ways, to catch problems with
length checks, or with nul terminator checks.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
This doesn’t trigger any new failures, but is distinct from other tests
we have, so would be good to retain.
Related to commit cec7170540.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
mntent-based implementation filter out mounts with device path that was
repeated. Consequently, it is not possible to show such mounts in UI even
with x-gvfs-show, because they are not returned from g_unix_mounts_get.
libmount-based implementation currently doesn't filter out any mounts
which causes issues to our volume monitors. Let's rather mark mounts
which don't point into fs root as system_internal. This approach won't be
affected by mount order as is mntent-based implementation. It will mark
more mounts as system_internal than it is filtered out with mntend-based
implementation, but there will be always possibility to show them in UI
over x-gvfs-show, which was not possible with mntend-based. We can
probably introduce some improvements later to not mark unique mounts as
system internal even if they don't point into fs root...
https://gitlab.gnome.org/GNOME/glib/issues/1271
Currently, there isn't API to determine root path for mounts created
over bind operation (or btrfs subvolumes). This causes issues to our
volume monitors if there is multiple mounts for one device, which can
happen with libmount-based implementation currently. Let's propagate
root path from libmount over g_unix_mount_get_root_path, so we can
handle this somehow in our volume monitors.
https://gitlab.gnome.org/GNOME/glib/issues/1271
These were callers which explicitly specified the string length to
g_utf8_validate(), when it couldn’t be negative, and hence should be
able to unconditionally benefit from the increased string handling
length.
At least one call site would have previously silently changed behaviour
if called with strings longer than G_MAXSSIZE in length.
Another call site was passing strlen(string) to g_utf8_validate(), which
seems pointless: just pass -1 instead, and let g_utf8_validate()
calculate the string length. Its behaviour on embedded nul bytes
wouldn’t change, as strlen() stops at the first one.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
This is a variant of g_utf8_validate() which requires the length to be
specified, thereby allowing string lengths up to G_MAXSIZE rather than
just G_MAXSSIZE.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
This introduces no real functional changes (except when compiling with
G_DISABLE_ASSERT, in which case it fixes the test). Mostly just a code
cleanup.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
The code was checking whether the signature provided by the blob was a
valid D-Bus signature — but that’s a superset of a valid GVariant type
string, since a D-Bus signature is zero or more complete types. A
GVariant type string is exactly one complete type.
This meant that a D-Bus message with a header field containing a variant
with an empty type signature (for example) could cause a critical
warning in the code parsing it.
Fix that by checking whether the string is a valid type string too.
Unit test included.
oss-fuzz#9810
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Parsing a D-Bus message with the signature field in the message header
of type other than ‘g’ (GVariant type signature) would cause a critical
warning. Instead, we should return a runtime error.
Includes a test.
oss-fuzz#9825
Signed-off-by: Philip Withnall <withnall@endlessm.com>
When validating a string to see if it’s valid UTF-8, we pass a gsize to
g_utf8_validate(), which only takes a gssize. For large gsize values,
this will result in the gssize actually being negative, which will
change g_utf8_validate()’s behaviour to stop at the first nul byte. That
would allow subsequent nul bytes through the string validator, against
its documented behaviour.
Add a test case.
oss-fuzz#10319
Signed-off-by: Philip Withnall <withnall@endlessm.com>
As with the previous commit, when getting a child from a serialised
tuple, check its offset against the length of the serialised data of the
tuple (excluding the length of the offset table). The offset was already
checked against the length of the entire serialised tuple (including the
offset table) — but a child should not be able to start inside the
offset table.
A test is included.
oss-fuzz#9803
Signed-off-by: Philip Withnall <withnall@endlessm.com>
When getting a child from a serialised variable array, check its offset
against the length of the serialised data of the array (excluding the
length of the offset table). The offset was already checked against the
length of the entire serialised array (including the offset table) — but a
child should not be able to start inside the offset table.
A test is included.
oss-fuzz#9803
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Previously, GVariant has allowed ‘arbitrary’ recursion on GVariantTypes,
but this isn’t really feasible. We have to deal with GVariants from
untrusted sources, and the nature of GVariantType means that another
level of recursion (and hence, for example, another stack frame in your
application) can be added with a single byte in a variant type signature
in the input. This gives malicious input sources far too much leverage
to cause deep stack recursion or massive memory allocations which can
DoS an application.
Limit recursion to 128 levels (which should be more than enough for
anyone™), document it and add a test. This is, handily, also the limit
of 64 applied by the D-Bus specification (§(Valid Signatures)), plus a
bit to allow wrapping of D-Bus messages in additional layers of
variants.
oss-fuzz#9857
Signed-off-by: Philip Withnall <withnall@endlessm.com>
When checking whether a serialised GVariant tuple is in normal form,
it’s possible for `offset_ptr -= offset_size` to underflow and wrap
around, resulting in gvs_read_unaligned_le() reading memory outside the
serialised GVariant bounds.
See §(Tuples) in gvariant-serialiser.c for the documentation on how
tuples are serialised. Briefly, all variable-length elements in the
tuple have an offset to their end stored in an array of offsets at the
end of the tuple. The width of each offset is in offset_size. offset_ptr
is added to the start of the serialised tuple to get the offset which is
currently being examined. The offset array is in reverse order compared
to the tuple elements, hence the subtraction.
The bug can be triggered if a tuple contains a load of variable-length
elements, each of whose length is actually zero (i.e. empty arrays).
Includes a unit test.
oss-fuzz#9801
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Emulated futexes are slower than real ones; if they were not, there
would be no point in using the real futexes. On some machines they
are sufficiently slow to cause test timeouts.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Fedora is using https://fedoraproject.org/wiki/Changes/Annobin
to try to ensure that all objects are built with hardening flags.
Pass down `CFLAGS` to ensure the SystemTap objects use them.
Without gatomic.h, build fails on:
In file included from garcbox.c:24:0:
garcbox.c: In function ‘g_atomic_rc_box_acquire’:
grefcount.h:101:13: error: implicit declaration of function ‘g_atomic_int_get’; did you mean ‘__atomic_store’? [-Werror=implicit-function-declaration]
(void) (g_atomic_int_get (rc) == G_MAXINT ? 0 : g_atomic_int_inc ((rc))); \
^
garcbox.c:292:3: note: in expansion of macro ‘g_atomic_ref_count_inc’
g_atomic_ref_count_inc (&real_box->ref_count);
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
We unconditionally appended ">= $min_glib_version" to the modules to
look for, even though we had already included
"glib-2.0 >= $min_glib_version" in our list. When requesting additional
modules, this was fine, for example
AM_PATH_GLIB_2_0([2.58], [:], [:], [gobject gio])
ended up asking pkg-config for
glib-2.0 >= 2.58 gobject-2.0 gio-2.0 >= 2.58
which is redundant (since they all share a version number) but
otherwise OK.
However,
AM_PATH_GLIB_2_0([2.58], [:], [:], [])
ended up asking pkg-config for
glib-2.0 >= 2.58 >= 2.58
which is not OK; the second ">=" was parsed as a bizarrely-named package
to check for, and obviously few people have ">=.pc" installed.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Fixes: 4bb16f48 "m4macros: Allow information from pkg-config to be overridden"
