Unfortunately, `g_memdup()` accepts its size argument as a `guint`,
unlike most other functions which deal with memory sizes — they all use
`gsize`. `gsize` is 64 bits on 64-bit machines, while `guint` is only 32
bits. This can lead to a silent (with default compiler warnings)
truncation of the value provided by the caller. For large values, this
will result in the returned heap allocation being significantly smaller
than the caller expects, which will then lead to buffer overflow
reads/writes.
Any code using `g_memdup()` should immediately port to `g_memdup2()` and
check the pointer arithmetic around their call site to ensure there
aren’t other overflows.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #2319
This will replace the existing `g_memdup()` function, which has an
unavoidable security flaw of taking its `byte_size` argument as a
`guint` rather than as a `gsize`. Most callers will expect it to be a
`gsize`, and may pass in large values which could silently be truncated,
resulting in an undersize allocation compared to what the caller
expects.
This could lead to a classic buffer overflow vulnerability for many
callers of `g_memdup()`.
`g_memdup2()`, in comparison, takes its `byte_size` as a `gsize`.
Spotted by Kevin Backhouse of GHSL.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: GHSL-2021-045
Helps: #2319
It may be defined by the environment (we document that as being allowed)
— if so, individual files should not try to redefine it, as that causes
a preprocessor warning.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
This is a utility function which I find myself writing in a number of
places. Mostly in unit tests.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
It’s perverse, but explicitly documented that strtoull() accepts numbers
with a leading minus sign (`-`) and explicitly casts them to signed
output.
g_ascii_strtoull() is documented to do what strtoull() does (but locale
independently), and its behaviour is correct. However, the documentation
could be a lot clearer about this unexpected behaviour.
Add a unit test for it too.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Very often when we want to convert a string to number, we assume that
the string contains only a number. We have g_ascii_strto* family of
functions to do the conversion but they are awkward to use - one has
to check if errno is zero, end_ptr is not NULL and *end_ptr points to
the terminating nul and then do the bounds checking. Many projects
need this kind of functionality, so it gets reimplemented all the
time.
This commit adds some replacement functions that convert a string to a
signed or unsigned number that also follows the usual way of error
reporting - returning FALSE on failure and filling an error output
parameter.
Add a check to configure.ac for strerror_r, since we don't currently
require POSIX.1-2001 conformance in general. Add back a
plain-strerror() case as a fallback, and rearrange the glibc-vs-POSIX
strerror_r() branches.
Update the docs to not claim that "not all platforms support the
strerror() function" (we require C90), but still mention the UTF-8 and
always-valid-string benefits. (And make test_strerror() check that
last part.)
https://bugzilla.gnome.org/show_bug.cgi?id=754788
Skip the tests on inf/nan strings for the gvariant and strfuncs tests, and
skip the hex strings for the strtod tests in strfuncs as they are C99
features that are not yet supported by Visual C++ (even 2013). Use a
definition for NAN and INFINITY (that is also used in PyGObject) as
atof("NaN") and atof("Infinity") simply returns 0.0 (which is not a NAN)
in Visual C++ to fix the tests running there.
Also adapt to the format of g_ascii_formatd() when dealing with 1e99.
https://bugzilla.gnome.org/show_bug.cgi?id=711047
fix enables g_strescape() and g_strcompress() to handle '\v' along with other
special characters - '\b', '\f', '\n', '\r', '\t', '\'.
https://bugzilla.gnome.org/show_bug.cgi?id=664830
Signed-off-by: Ravi Sankar Guntur <ravi.g@samsung.com>
Some of the GLib tests deliberately provoke warnings (or even fatal
errors) in a forked child. Normally, this is fine, but under valgrind
it's somewhat undesirable. We do want to follow fork(), so we can check
for leaks in child processes that exit gracefully; but we don't want to
be told about "leaks" in processes that are crashing, because there'd
be no point in cleaning those up anyway.
https://bugzilla.gnome.org/show_bug.cgi?id=666116
These don't really matter, since it's test code, but they do obscure
real leaks in the library.
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=666115
Acked-by: Matthias Clasen <mclasen@redhat.com>
This has uncovered two unused testcases in option-context.c. They are
currently broken and require more investigation (which is probably why
they are unused).
2008-08-28 Ryan Lortie <desrt@desrt.ca>
Fixup for test case in previous commit.
* glib/tests/strfuncs.c: don't fail if we can't open the test data.
This happens if $(builddir) != $(srcdir) (like when doing 'make
distcheck'). Quick workaround for now until #549783 can be fixed.
svn path=/trunk/; revision=7415
2008-08-28 Ryan Lortie <desrt@desrt.ca>
[REVERT] Bug 548612 – g_strstr_len() should use memmem when available
* glib/gstrfuncs.c (g_strstr_len): fix off-by-one memory access error
* glib/tests/strfuncs.c (test_bounds): add some new test cases that
would catch problems like this
* glib/tests/4096-random-bytes: test data for the previous
* glib/tests/Makefile.am: add previous to EXTRA_DIST
svn path=/trunk/; revision=7414
2008-08-28 Bastien Nocera <hadess@hadess.net>
Bug 548612 – g_strstr_len() should use memmem when available
* glib/tests/strfuncs.c (test_strstr):
* tests/string-test.c (main): Patch by Paolo Borelli
<pborelli@katamail.com> to move the tests to the right place,
and add more tests
* glib/gstrfuncs.c (g_strstr_len): Fix problem with memmem ignoring
nul-terminators in strings, and using the haystack_len instead
svn path=/trunk/; revision=7409
2008-06-24 Paolo Borelli <pborelli@katamail.com>
Bug 539770 - migrate gstrfunc unit tests to gtest
* tests/strfunc-test.c:
* tests/testglib.c:
* tests/strtoll-test.c:
* tests/strtod-test.c:
* tests/string-test.c:
* tests/Makefile.am:
Removed old tests.
* glib/tests/fileutils.c:
* glib/tests/strfuncs.c:
* glib/tests/Makefile.am:
Added all the old tests migrated to the new unit test framework
and add new unit tests for some of the functions.
svn path=/trunk/; revision=7097
