Synchronize access to random number generator `test_run_rand` with
a lock to ensure that `g_test_rand_*` family of functions is
thread-safe.
The reseeding taking place between test case runs is intentionally left
unsynchronized. It is an error to continue using random number generator
after test case has already finished running. Lack of synchronization
here will make such erroneous use readily apparent with thread
sanitizer.
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 reverts commits:
• 9ddcc79502349e02a1e796b363d891e177337af5
• ae02adc3c3795bb32348c07d8f48504b41e9e2c7
g_date_time_format() supports a few non-standard format placeholders:
• %:z
• %::z
• %:::z
These are all gnulib strtime() extensions, and hence are not recognised
by the compiler when the function is annotated with G_GNUC_STRFTIME.
However, this wasn’t noticed when we originally merged this change
because the errors were disabled in the tests which covered those
placeholders.
This does not work, since g_date_time_format() supports
non-standard extensions such as %:::z, and this has
broken several consumers which use format errors, such
as ostree.
This is desirable both to get more detailed failure messages; and
because g_assert() is compiled out when compiling with G_DISABLE_ASSERT,
which renders the tests useless.
Signed-off-by: Christophe Fergeau <cfergeau@redhat.com>
gint is not the best type when looping from 0 to N > 0, which usually is
the case in loops. There are a few cases in this patch where guint is
used rather than gsize, this is when the index is used in a printf-like
function as this makes the format string easier to read
Signed-off-by: Christophe Fergeau <cfergeau@redhat.com>
Formatting code for `%z` specifier incorrectly assumed that sign of
offset from UTC can be recovered from the number of hours alone, which
is not true for offsets between -01:00 and +00:00.
Extract and format sign separately to avoid the problem.
Issue #1337.
Previously, the code which parsed comments in key files would append a
line break to the comment where there was none before; this was part of
the code for handling re-inserting line breaks into multi-line comments
after removing the ‘#’ prefix. Now, we don’t add a terminal line break.
This was slightly icky to implement because parse_value_as_comment() is
called once for each line of a multi-line comment.
This expands the existing test case to cover a single line comment, and
also fixes the documentation to correctly state that the leading ‘#’
*is* removed and mention the new line break behaviour.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://gitlab.gnome.org/GNOME/glib/issues/107
When g_date_set_parse was used with more than one locale it could
incorrectly retain information from previous one. Reinitialize all
locale specific data inside g_date_prepare_to_parse to avoid the issue.
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.
