| Age | Commit message (Collapse) | Author |
|---|
|
Previously, the exit condition was inverted, causing the fuzzer to
try to read the value of an error.
|
|
|
|
|
|
|
|
This prevents callers from accidentally discarding the result of
initialize(), which was the root cause of this OSS Fuzz bug:
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=55896&q=label%3AProj-serenity&sort=summary
|
|
Previously, the condition was reversed, so we would stop immediately on
a file that has at least one working chunk, and we would infinitely loop
on a file with no chunks.
|
|
|
|
|
|
Loads of changes that are tightly connected... :/
* Change lambdas to static functions
* Add spec docs to those functions
* Keep the current scope around as a parameter
* Add wrapping classes for some Certificate members
* Parse ec and ecdsa data from certificates
|
|
|
|
|
|
|
|
|
|
Turns out LLVMFuzzerTestOneInput may be called more than once per
process.
|
|
Invalid UTF-8 crashes JS::Script::Parse.
|
|
|
|
|
|
Before, some loader plugins implemented their own buffering (FLAC&MP3),
some didn't require any (WAV), and some didn't buffer at all (QOA). This
meant that in practice, while you could load arbitrary amounts of
samples from some loader plugins, you couldn't do that with some others.
Also, it was ill-defined how many samples you would actually get back
from a get_more_samples call.
This commit fixes that by introducing a layer of abstraction between the
loader and its plugins (because that's the whole point of having the
extra class!). The plugins now only implement a load_chunks() function,
which is much simpler to implement and allows plugins to play fast and
loose with what they actually return. Basically, they can return many
chunks of samples, where one chunk is simply a convenient block of
samples to load. In fact, some loaders such as FLAC and QOA have
separate internal functions for loading exactly one chunk. The loaders
*should* load as many chunks as necessary for the sample count to be
reached or surpassed (the latter simplifies loading loops in the
implementations, since you don't need to know how large your next chunk
is going to be; a problem for e.g. FLAC). If a plugin has no problems
returning data of arbitrary size (currently WAV), it can return a single
chunk that exactly (or roughly) matches the requested sample count. If a
plugin is at the stream end, it can also return less samples than was
requested! The loader can handle all of these cases and may call into
load_chunk multiple times. If the plugin returns an empty chunk list (or
only empty chunks; again, they can play fast and loose), the loader
takes that as a stream end signal. Otherwise, the loader will always
return exactly as many samples as the user requested. Buffering is
handled by the loader, allowing any underlying plugin to deal with any
weird sample count requirement the user throws at it (looking at you,
SoundPlayer!).
This (not accidentally!) makes QOA work in SoundPlayer.
|
|
|
|
|
|
The LibWeb fuzzer build is really slow, so for local builds it is useful
to disable it when you're not interested in running that fuzzer.
Co-authored-by: Andrew Kaster <akaster@serenityos.org>
|
|
|
|
|
|
The patch also contains modifications on several classes, functions or
files that are related to the `JPGLoader`.
Renaming include:
- JPGLoader{.h, .cpp}
- JPGImageDecoderPlugin
- JPGLoadingContext
- JPG_DEBUG
- decode_jpg
- FuzzJPGLoader.cpp
- Few string literals or texts
|
|
We don't need a full String/DeprecatedString inside this function, so we
might as well not force users to create one.
|
|
|
|
|
|
|
|
|
|
Note that as of this commit, there aren't any such throwers, and the
call site in Heap::allocate will drop exceptions on the floor. This
commit only serves to change the declaration of the overrides, make sure
they return an empty value, and to propagate OOM errors frm their base
initialize invocations.
|
|
|
|
|
|
|
|
When trying to figure out the correct implementation, we now have a very
strong distinction on plugins that are well suited for sniffing, and
plugins that need a MIME type to be chosen.
Instead of having multiple calls to non-static virtual sniff methods for
each Image decoding plugin, we have 2 static methods for each
implementation:
1. The sniff method, which in contrast to the old method, gets a
ReadonlyBytes parameter and ensures we can figure out the result
with zero heap allocations for most implementations.
2. The create method, which just creates a new instance so we don't
expose the constructor to everyone anymore.
In addition to that, we have a new virtual method called initialize,
which has a per-implementation initialization pattern to actually ensure
each implementation can construct a decoder object, and then have a
correct context being applied to it for the actual decoding.
|
|
JS::Value::to_string now returns a String, which does not have a null-
terminated characters() accessor.
|
|
|
|
|
|
This also slightly improves error propagation in tar, unzip and zip.
|
|
|
|
OpenType is the backwards-compatible successor to TrueType, and the
format we're actually parsing in LibGfx. So let's call it that.
|
|
This is to differentiate between the upcoming `AllocatingMemoryStream`,
which automatically allocates memory as needed instead of operating on a
static memory area.
|
|
This generally seems like a better name, especially if we somehow also
need a better name for "read the entire buffer, but not the entire file"
somewhere down the line.
|
|
LibFuzzer documentation [1] states that all return values except for 0
and -1 are currently reserved for future use. -1 is a special return
value that causes LibFuzzer to not add a testing input to the testing
corpus, regardless of the code coverage that it causes.
[1] https://llvm.org/docs/LibFuzzer.html
|
|
|
|
We have a new, improved string type coming up in AK (OOM aware, no null
state), and while it's going to use UTF-8, the name UTF8String is a
mouthful - so let's free up the String name by renaming the existing
class.
Making the old one have an annoying name will hopefully also help with
quick adoption :^)
|
|
This now prepares all the needed (fallible) components before actually
constructing a LoaderPlugin object, so we are no longer filling them in
at an arbitrary later point in time.
|
|
|
|
This now also validates the first header that is loaded, so we can drop
the corresponding FIXME from `tar`.
|
|
|
|
Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=53733
This bug was caused by a regression introduced in c88d8a2.
|
