| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add SPDX license (but not copyright) headers to all files which follow a
certain pattern in their existing non-machine-readable header comment.
This commit was entirely generated using the command:
```
git ls-files glib/*.[ch] | xargs perl -0777 -pi -e 's/\n \*\n \* This library is free software; you can redistribute it and\/or\n \* modify it under the terms of the GNU Lesser General Public/\n \*\n \* SPDX-License-Identifier: LGPL-2.1-or-later\n \*\n \* This library is free software; you can redistribute it and\/or\n \* modify it under the terms of the GNU Lesser General Public/igs'
```
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #1415
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes a bug in 7c4e6e9fbe473de0401c778c6b0c4aad27d5145a.
The original approach in that commit accidentally only checked the depth
at the leaf nodes in the variant tree, whereas actually the depth should
be checked before recursing to avoid stack overflow.
It neglected to consider that `g_variant_serialised_is_normal()` would
be recursed into by some of the `DISPATCH(_is_normal)` cases. When that
happened, the depth check was after the recursion so couldn’t prevent a
stack overflow.
Fixes: #2572
|
| |
|
|
|
|
|
|
| |
Changes serialis* to serializ*.
Fixes: #2399
Signed-off-by: Geyslan G. Bem <geyslan@gmail.com>
|
| |
|
|
|
|
| |
This introduces no functional changes.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
|
| |
|
|
|
|
|
|
|
|
| |
Rather than duplicating the alignment checks when constructing a new
GVariant, re-use the alignment checks from GVariantSerialised. This
ensures that the same checks are done everywhere in the GVariant code.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://gitlab.gnome.org/GNOME/glib/issues/1342
|
| |
|
|
| |
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>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
All glib/*.{c,h} files have been processed, as well as gtester-report.
12 of those files are not licensed under LGPL:
gbsearcharray.h
gconstructor.h
glibintl.h
gmirroringtable.h
gscripttable.h
gtranslit-data.h
gunibreak.h
gunichartables.h
gunicomp.h
gunidecomp.h
valgrind.h
win_iconv.c
Some of them are generated files, some are licensed under a BSD-style
license and win_iconv.c is in the public domain.
Sub-directories inside glib/:
deprecated/: processed in a previous commit
glib-mirroring-tab/: already LGPLv2.1+
gnulib/: not modified, the code is copied from gnulib
libcharset/: a copy
pcre/: a copy
tests/: processed in a previous commit
https://bugzilla.gnome.org/show_bug.cgi?id=776504
|
| |
|
|
|
|
|
|
| |
If we have an input parameter (or return value) we need to use (nullable).
However, if it is an (inout) or (out) parameter, (optional) is sufficient.
It looks like (nullable) could be used for everything according to the
Annotation documentation, but (optional) is more specific.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This probably won’t crash, as it can only happen if (size == 0), but
add a check to be safe, and to shut up the static analyser.
This case can be reached with the following call:
gvs_read_unaligned_le(NULL, 0)
which can be called from:
gvs_tuple_get_child(value, index_)
with (value.data == NULL) and (value.size == 0).
Found by scan-build.
https://bugzilla.gnome.org/show_bug.cgi?id=715164
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
GVariant has the concept of fixed-sized types (ie: types for which all
values of the type will have the same size). Examples are booleans,
integers, doubles, etc. Tuples containing only these types are also
fixed size.
When GVariant is trying to deal with a fixed-sized value for which it
doesn't have a sufficient backing store (eg: the case where a
fixed-sized value was created with g_variant_new_data() with an
incorrect number of bytes) it denotes this by setting the size of the
value to the correct fixed size but using a NULL data pointer.
This is well-documented in several code comments and also in the public
API documentation for g_variant_get_data() which describes the situation
number which NULL could be returned.
The decision to deal with this case in this way was changed at the last
minute around the time that GVariant was merged -- originally we had an
elaborate setup involving allocating an internal buffer of sufficient
size to be shared between all invalid values.
Unfortunately, when making this change a small detail was missed.
gvs_tuple_get_child() (the function responsible for deserialising
tuples) was updated to properly check for this case (and it contains a
comment about why it must). gvs_tuple_is_normal() (the function
responsible for verifying if a tuple is in normal form) was not.
We add the check now.
Note that this problem does not exist with any other container type
because tuples are the only container capable of being fixed-sized. All
other container types (arrays, maybes, variants) can contain a variable
number of items or items of variable types (note: we consider dictionary
entries to be two-tuples). The code for validating non-container values
also contains a check for the case of NULL data.
The problem also does not occur in the only other function dealing with
serialised tuples: gvs_tuple_n_children(). Whereas other container
types would have to inspect the serialised data to determine the number
of children, for tuples it can be determined directly from the type.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
String validation was done by checking if the string was valid utf8 and
ensuring that the first non-utf8 character was the last character (ie:
the nul terminator).
No check was actually done to make sure that this byte actually
contained a nul, however, so it was possible that you could have a
string like "hello\xff" with length 6 that would correctly validate.
Fix that, and test it.
|
| |
|
|
|
| |
Found using:
find . -name '*.c' | xargs grep 'or %NULL' | grep ' \* @' | grep -v '@error' | grep -v allow-none
|
| | |
|
| |
|
|
|
| |
Spelling fixes in comments and docs, provided by
Kjartan Maraas in bug 657336.
|
| | |
|
| |
|
|
|
| |
Fix some GVariant bugs uncovered by calling g_variant_new_from_data with
invalid data (which it should be immune to).
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
FreeBSD's malloc() sometimes returns unaligned memory if you are
requesting small sizes. This can get GVariant into trouble. For
example, consider the type "mmi" containing the value "just nothing".
According to the type signature, the memory containing this should be
aligned to a boundary of 4 since it might contain an int. The
serialised size of this value is 1 byte, however, and when you ask
FreeBSD to allocate memory of that size, it knows you can't put an int
into it so it doesn't bother aligning it.
This patch modifies the GVariant serialiser to not assert the alignment
constraint in the case that the size of the serialised data is smaller
than its own alignment requirement.
|
| |
|
|
| |
Closes bug #619585.
|
| |
|
|
|
|
|
| |
- modify serialiser validation function to enforce utf8 encoding
- add documentation to g_variant_new_string(), g_variant_get_string(),
g_variant_dup_string()
- add 2 new test cases to check that it works
|
| |
|
|
| |
In particular, tested with Microsoft Visual C 2008.
|
| |
|
|
| |
Closes bug #612327 reported by Claudio Saavedra.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Merge GVariant variable arguments support and put it under tests.
Also, remove the hack of the test case directly '#include'ing .c files
from glib/. Instead, create a non-installed gvariant-internal.h that
the tests can include and make the symbols in it visible on the symbol
table of the shared library. These symbols (as they are present in no
installed header files) are not part of the API of GLib.
Increase test coverage in a few other areas.
|
| |
|
|
| |
also: white-space fix in the serialiser
|
| | |
|
| |
|
