g_source_set_callback() and g_source_set_callback_indirect() are both
safe to call zero or more times on attached sources. The change in
callback will take effect the next time the source is dispatched, after
the set_callback() call returns (it could block due to locking).
https://gitlab.gnome.org/GNOME/glib/issues/827
FreeBSD 12 adds a new header, sys/auxv.h, to declare a function, elf_aux_info,
for public use, which was considered an internal function in previous releases.
This new function provides similar functionality with glibc getauxval, which is
also declared in the same header, but their interfaces are not compatible. Since
the only usage of sys/auxv.h is in g_check_setuid and FreeBSD already has
issetugid to provide the required functionality, we fixes the compilation error
by adding a check for getauxval function to prevent g_check_setuid from calling
getauxval when sys/auxv.h is found but getauxval is not available.
https://reviews.freebsd.org/D12743https://reviews.freebsd.org/rS324815
Previously, the markup parsing test would load a given markup file and
try to parse it several ways. It would return as soon as one of the
attempts failed — meaning that bugs only seen with non-nul-terminated,
or differently chunked, parse runs could never be caught.
Rework the tests so that all markup files are tested all ways, and we
assert that all ways of parsing them give the same result.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Previously, the element name validation only happened if a start_element
callback was specified on the context. Element name validation should be
unconditional.
This was causing test-5.gmarkup to fail when run against the improved
tests in the following commit.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
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 cec71705406f0b2790422f0c1aa0ff3b4b464b1b.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
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>
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>
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
A double paren forces the compiler to assume that the
statement is right. That may not be the case.
This is essentially reverting b44fba25fbad89c105795a10a569fe422e4d1c44.
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.
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>
We still clear the key/value on removal, but since we're growing the
arrays with realloc() now, we can't guarantee that incoming memory is
cleared. There's no reason it should be either, since we check the
hashes array (which is always in a defined state) before accessing the
other arrays.
When g_hash_table_resize() gets called, we clear out tombstones and grow
the table at the same time if needed. However, the threshold was set too
low, so we'd grow if the load was greater than .5 after subtracting
tombstones. Increase this threshold to ~.75.
When resizing, we were keeping both the old and new hash, key and value
arrays around while we reinserted entries, resulting in a peak memory
overhead of 50%. Using a temporary bookkeeping array with one bit per
entry we can now grow and shrink the main arrays using realloc() and an
eviction scheme, reducing the overhead to .625% (assuming 64-bit keys and
values). Tests show the CPU overhead is negligible.
If int is smaller than void * on our arch, we start out with
int-sized keys and values and resize to pointer-sized entries as
needed. This saves a good amount of memory when the HT is being
used with e.g. GUINT_TO_POINTER().
I’m fed up of trying to read these and having my head done in by mixed
tabs and spaces.
This introduces no functional changes.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
This avoids the convenience library being treated as though it was
an installed static library (objects not included in the dependent
static library, and convenience library being listed in the pkg-config
metadata), both of which would make static linking impossible.
This is a workaround for meson not having
https://github.com/mesonbuild/meson/pull/3939 merged yet.
Fixes: https://gitlab.gnome.org/GNOME/glib/issues/1536
Signed-off-by: Simon McVittie <smcv@collabora.com>
