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>
armv5 Linux systems implement __sync_bool_compare_and_swap() and
friends by calling a function provided by the kernel. This is not
technically an atomic intrinsic, so gcc doesn't define
__GCC_HAVE_SYNC_COMPARE_AND_SWAP_4 in this case, but it's good
enough for us. Extend the current Android special case to cover
GNU/Linux too.
The possibilities are:
* __sync_foo detected and __GCC_HAVE_SYNC_COMPARE_AND_SWAP_4 predefined:
calls to __atomic_foo or __sync_foo primitives are inlined into user
code by gatomic.h
* __sync_foo detected but __GCC_HAVE_SYNC_COMPARE_AND_SWAP_4 not
predefined: user code has an extern reference to g_atomic_foo(),
which calls __atomic_foo or __sync_foo because we defined
__GCC_HAVE_SYNC_COMPARE_AND_SWAP_4 when compiling GLib itself
* Windows: user code has an extern reference to g_atomic_foo(),
which calls InterlockedFoo()
* !defined(G_ATOMIC_LOCK_FREE): user code has an extern reference to
g_atomic_foo(), which emulates atomic operations with a mutex
Signed-off-by: Simon McVittie <smcv@collabora.com>
Closes: #1576
This test isn't inherently slow, but it produces so much output that
it can take a minute or more on hardware with weak I/O performance.
Signed-off-by: Simon McVittie <smcv@collabora.com>
This is enough for most Debian buildds, including embedded devices
like mips and powerpcspe. It is not enough for hppa (PA-RISC), but that
architecture is so uniquely slow that it might make more sense to
special-case it downstream.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Currently, readlink() is used only 12 times when expanding symlinks.
However, kernel uses 40 for this purpose and it is defined as MAXSYMLINKS.
Use that constant if available, or 40. See:
https://github.com/torvalds/linux/include/linux/namei.h.
find_mountpoint_for() uses current file in case of error, because
get_parent() returns NULL for error, but also if parent doesn't exist.
Return "." from get_parent() if parent doesn't exist in order to
differentiate the error state.
Test symlink expansion in find_mountpoint_for() function over
_g_local_file_find_topdir_for(). find_mount_for() is crucial for many
of glocalfile.c functionality (e.g. to determine correct trash location)
and symlink expansion has to work properly.
https://gitlab.gnome.org/GNOME/glib/issues/1522
G_FILE_ATTRIBUTE_ACCESS_CAN_TRASH can be set to a wrong value if
its parent dir is a symlink. This is because the find_mountpoint_for()
function tries to find mountpoint for a filepath and expands symlinks
only in parent dirs. But in this case the path is already parent dir
and needs to be expanded first...
Closes: https://gitlab.gnome.org/GNOME/glib/issues/1522
This is the most degenerate possible test but it does exercise this code
path.
(Tweaked by Philip Withnall <withnall@endlessm.com> to also add the flag
to the autotools build.)
gdbus-peer: Make sure to not include objectmanager-gen.c source
See merge request GNOME/glib!416
(cherry picked from commit 4d48e020278b6be64ba84be7b8ab388f5ff2b358)
7c70bef8 gdbus-peer: Make sure to not include objectmanager-gen.c source
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>
meson: Mark 1bit-emufutex test as slow
See merge request GNOME/glib!406
(cherry picked from commit 5c22b2ddde21c9080d1a9a090e1945f7a1d4c5f2)
442b54f0 meson: Mark 1bit-emufutex test as slow
libmount-based implementation doesn't filter out mounts with device
path that was repeated as it is done with mntent-based implementation.
It causes problems to our volume monitors which are not able to handle
multiple mounts for one device path properly without additional API.
Let's filter out the same mounts as are filtered out with mntent-based
implementation.
This is intended only for stable branches to prevent current issues.
https://gitlab.gnome.org/GNOME/glib/issues/1271
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"
By using PKG_CHECK_VAR, we declare $GLIB_COMPILE_SCHEMAS,
$GLIB_GENMARSHAL, $GOBJECT_QUERY, $GLIB_MKENUMS and
$GLIB_COMPILE_RESOURCES as Autoconf "precious variables" with AC_ARG_VAR,
similar to $PKG_CONFIG and $CC, so that they can be put on a configure
command line:
./configure GLIB_COMPILE_RESOURCES=my-glib-compile-resources
If they are set to a non-empty value, PKG_CHECK_VAR will use that
instead of auto-detecting from pkg-config, so that builders can
override them, for example when cross-compiling.
Similarly, use the standard PKG_CHECK_MODULES macro to get GLib's CFLAGS
and LIBS.
It's possible that most of the rest of each macro can also disappear,
but for the moment I've given them the benefit of the doubt.
This does result in printing "checking for GLIB" twice (once for
PKG_CHECK_MODULES and once for GLib's custom checks), but if you're
using Autotools, you probably don't have a strong objection to overly
verbose output.
Signed-off-by: Simon McVittie <smcv@collabora.com>
libmount depends on libblkid, so if we statically link a trivial
executable to GIO, we need to pull in both libmount and libblkid.
Linking with -lmount is not enough to achieve that, but recursing
into mount.pc is.
This makes the Autotools build a bit more like the Meson build,
which already puts mount in Requires.private.
Signed-off-by: Simon McVittie <smcv@collabora.com>
