valgrind spotted this one: a read off the end of the `stop_chars` buffer
when `stop_chars_len == -1`, due to the fuzzing test not sticking to the
requirement from `g_data_input_stream_read_upto()` that `stop_chars`
must be nul-terminated if `stop_chars_len < 0`.
This can happen when reading `fuzzing/README.md`, which is done as a
smoketest when the fuzzing tests are run without the fuzzer, as normal
unit tests. In this case, it made smoke.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
While reading a single byte or uint16 from an input stream is fairly
simple and uncontroversial, the code to read a line or read up to any of
a set of stop characters is not so trivial. People may be using
`GDataInputStream` to parse untrusted input like this, so we should
probably test that it’s robust against a variety of input conditions.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Limit the input size. With a short @find, and a long `init` and `replace`
it’s quite possible to hit OOM. We’re not interested in testing that — it’s
up to the caller of `g_string_replace()` to handle that. 1KB on each of the
inputs should be plenty to find any string parsing or pointer arithmetic
bugs in `g_string_replace()`.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
oss-fuzz#371233785
Now that the implementation of it is significantly more complex,
involving pointer arithmetic, it should probably be fuzzed. It’s not an
API which is obviously used to handle untrusted input, but some users of
GLib might do so.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
The symbols still have to be exported from the library (since they’re
called from unit tests), but there was never any reason for them to be
in a public header.
This means they now disappear from `Gio-2.0.gir`.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3231
The behaviour of `g_variant_byteswap()` is largely dominated by its call
to `g_variant_get_normal_form()`, but it does do an additional call to
`g_variant_serialised_byteswap()` which we should probably be fuzzing.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
We don't need a cpp toolchain for building glib so lets just
automatically disable tests requiring one when not available.
Signed-off-by: James Hilliard <james.hilliard1@gmail.com>
The files have only been touched by a subset of three people: pdknsk,
Philip Withnall, and Marc-André Lureau. Their copyrights are assigned to
pdknsk, Endless OS Foundation and Red Hat.
The default license for GLib at the time of writing these files was (and
still is) LGPL-2.1-or-later.
`driver.c` came from LLVM and is under a different license:
https://github.com/llvm/llvm-project/blob/main/compiler-rt/lib/fuzzer/standalone/StandaloneFuzzTargetMain.c.
That doesn’t affect the license of GLib overall, since it’s only used
for testing during development.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #1415
Test the fuzzers with one arbitrary input each, to ensure that they work
at a very basic level.
This should catch regressions in each of the fuzzers without having to
wait for them to be picked up by oss-fuzz.
These tests can be run using `meson test --suite fuzzing`.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
https://gitlab.gnome.org/GNOME/glib/-/jobs/1875915
```
../fuzzing/fuzz_paths.c: In function ‘LLVMFuzzerTestOneInput’:
../fuzzing/fuzz_paths.c:7:16: error: variable ‘skipped_root’ set but not used [-Werror=unused-but-set-variable]
7 | const gchar *skipped_root;
| ^~~~~~~~~~~~
cc1: all warnings being treated as errors
```
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Update several links to allow the remote to use its configured default
branch name, rather than specifying `master` as the default branch name.
This will help avoid breakage if any of these projects rename their
default branch in the future.
Fix a few of the links where they were hitting redirects or had moved.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #2348
If operating on a zero-length input, the return values of
`g_path_get_basename()` and `g_path_get_dirname()` are correctly `.`.
The assertions in the test didn’t account for this.
oss-fuzz#32454
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
fuzzing/fuzz_dbus_message.c:3:1: error: ‘static’ is not at beginning of declaration
3 | const static GDBusCapabilityFlags flags = G_DBUS_CAPABILITY_FLAGS_UNIX_FD_PASSING;
| ^~~~~
There’s no explicit guarantee that any of these functions are safe to
use on untrusted data, but it does no harm to test them.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Make `G_URI_FLAGS_PARSE_RELAXED` available instead, for the
implementations which need to handle user-provided or incorrect URIs.
The default should nudge people towards being compliant with RFC 3986.
This required also adding a new `G_URI_PARAMS_PARSE_RELAXED` flag, as
previously parsing param strings *always* used relaxed mode and there
was no way to control it. Now it defaults to using strict mode, and the
new flag allows for relaxed mode to be enabled if needed.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Fixes: #2149
It's not clear to me why this argument was excluded in the first place,
and Dan doesn't remember either. At least for consistency with
unescape_string, add it.
See also:
https://gitlab.gnome.org/GNOME/glib/-/merge_requests/1574#note_867283
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
This will allow to further enhance the parsing, without breaking API,
and also makes argument on call side a bit clearer than just TRUE/FALSE.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
This should give a bit more flexibility, without drawbacks.
Many URI encoding accept either '&' or ';' as separators.
Change the documentation to reflect that '&' is probably more
common (http query string).
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
The fuzzer will produce arbitrary binary blobs, which might not be
nul-terminated. `g_uri_parse()` has no length argument, so relies on
receiving a nul-terminated string as input. Guarantee that.
This should fix fuzzing build failures like
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=23750.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
