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>
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
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"
An assertion is harder to skip over, and using a g_critical() can give
us a more informative error message.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://gitlab.gnome.org/GNOME/glib/issues/179
There were tests for invalid UTF-8 output when asynchronously
communicating with a subprocess, but nothing for synchronous
communication. Add such a test, and refine the code as a result.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Instead of sometimes returning a non-NULL buffer, always return NULL.
However, keep the documentation as explicitly returning undefined values
on failure, so that we can change the behaviour in future if needed.
The return values weren’t defined for failure before, so were
implicitly returning undefined values.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
This works around weird issues MS C runtime has when dealing
with timestamps close to zero, where timezone adjustment could result
in a negative timestamp.
Put the core readlink() code into a separate
_g_win32_readlink_handle_raw() function that takes a file handle,
can optionally ensure NUL-terminatedness of its output
(for cases where we need a NUL-terminator and do *not* need
to get the exact contents of the symlink as it is stored in FS)
and can either fill a caller-provided buffer *or* allocate
its own buffer, and can also read the reparse tag.
Put the rest of readlink() code into separate
functions that do UTF-16<->UTF-8, strip inconvenient prefix
and open/close the symlink file handle as needed.
Split _g_win32_stat_utf16_no_trailing_slashes() into
two functions - the one that takes a filename and the one
that takes a file descriptor. The part of these functions
that would have been duplicate is now split into the
_g_win32_fill_privatestat() funcion.
Add more comments explaining what each function does.
Only g_win32_readlink_utf8(), which is callable from outside
via private function interface, gets a real doc-comment,
the rest get normal, non-doc comments.
Change all callers to use the new version of the private
g_win32_readlink_utf8() function, which can now NUL-terminate
and allocate on demand - no need to call it in a loop.
Also, the new code should correctly get reparse tag when the
caller does fstat() on a symlink. Do note that this requires
the caller to get a FD for the symlink, not the target. Figuring
out how to do that is up to the caller.
Since symlink info (target path and reparse tag) are now always
read directly, via DeviceIoControl(), we don't need to use
FindFirstFileW() anymore.
All pool threads are named "pool" and this a bit annoying when looking
at system-wide traces or statistics for a system where several
applications use thread pools. Include the prgname in the thread names
to get a better default name. The total length including the "pool-"
prefix is limited to 16 bytes in order for it to work on all systems.
Change-Id: I473a9f534c4630f3e81da72ff96d8f593c60efac
On Windows NTFS symlinks are implemented as reparse points,
which are special kinds of files *or directories*. A directory
symlink should link to a directory. A file symlink should link
to a file. Mismatching (such as a file symlink pointing to a
directory) produces symlinks that simply do not function.
Therefore GFileType file vs directory vs symlink distinction is
too simplistic to correctly represent a NTFS filesystem object type.
Since we can't turn back time and choose a better way of representing
file types, make GFileType reflect the file vs directory type on
Windows, meaning that all FS objects are either files or
directories (or shortcuts, which are also files), but never symlinks.
A test for symlinkiness will have to be made via GFileInfo - it
tracks symlinkiness separately from file/directory/whatever.
Since we are unable to promote our FreeBSD runner to a shared runner,
we can only enable it in GNOME group. This should avoid problems when
submitting merge requests from forks.
A double paren forces the compiler to assume that the
statement is right. That may not be the case.
This is essentially reverting b44fba25fb.
See https://bugzilla.gnome.org/show_bug.cgi?id=760215.
It's more morth to allow find common mistakes (= instead of ==
in conditionals) than masking them to make some rarely used
code work.
While we can’t add markers to the macro implementations to cause lcov to
ignore them automatically, we can change our lcov configuration to
ignore all calls to them.
See https://github.com/linux-test-project/lcov/issues/44.
This causes all the un-takeable branches and un-reachable assertions to
be ignored by our code coverage, which bumps our statistics:
• Lines: 74.9% → 74.8%
• Functions: 82.3% → 82.3%
• Branches: 53.3% → 64.2%
The rationale is that nobody should be testing programmer error
handling, as g_return_*if_fail() are used to guard against — so it’s not
reasonable to count missed branches like that in code coverage
statistics.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
As we use pthread_rwlock_*() to implement GRWLock (on Unix), the
priority of readers vs writers when trying to acquire a lock already
held by one reader with a writer queued, is unspecified. i.e. We don’t
explicitly prioritise the pending readers to acquire the lock (and block
the writer), or vice-versa.
Whatever our implementation on other platforms, we must document the
priority as unspecified, as that’s what happens on Unix and is the
least restrictive API guarantee we can make.
Prompted by https://stackoverflow.com/q/52661672/2931197.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
The st_nlink field of the stat structure has meaning and should
be put into GFileInfo.
The st_mode field is far less meaningful, but could still be used
for some purposes, adjust the comment to clarify that.
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>
