AccessViolationException in class constructors

[fuzzah]

After instrumenting my code with SharpFuzz I get constant System.AccessViolationExceptions even without fuzzing.
I don't know what exactly causes it, but it seems to always happen in constructors.
I have prepared a tiny reproducer app.

Reproduce:

1. Download the attached reproduce.tar.gz archive. It contains the source code for two projects: the FuzzMe is an application under test and the FuzzMe.Fuzz is the fuzzing harness.
2. Extract the archive: tar zxvf reproduce.tar.gz
3. [Review the code]
4. Build the FuzzMe.Fuzz app. No errors should pop up:

cd reproduce/tests/FuzzMe.Fuzz
dotnet publish -c Release --self-contained -r linux-x64

5. Make sure the FuzzMe.Fuzz app raises no exceptions:

echo test | ./bin/Release/net6.0/linux-x64/FuzzMe.Fuzz

6. Instrument FuzzMe* classes within the FuzzMe.dll with SharpFuzz:

export SHARPFUZZ_PRINT_INSTRUMENTED_TYPES=1
sharpfuzz ./bin/Release/net6.0/linux-x64/FuzzMe.dll FuzzMe

It should print:

FuzzMe.Parser
FuzzMe.Point
FuzzMe.Program

7. Run the app again and observe the exception:

echo test | ./bin/Release/net6.0/linux-x64/FuzzMe.Fuzz

The output looks like this:

Fatal error. System.AccessViolationException: Attempted to read or write protected memory. This is often an indication that other memory is corrupt.
   at FuzzMe.Point..ctor(Int32, Int32)
   at FuzzMe.Fuzz.Program.Main(System.String[])
Aborted (core dumped)

The exit code is 134.

The SharpFuzz dependency is 2.0.1 and the SharpFuzz.CommandLine tool is also 2.0.1.

There are private/protected readonly fields in the constructors of Point and Parser classes, but changing them to public (and without readonly) changes nothing.

Is there some limitation in SharpFuzz regarding constructors? The real code I wish to test has lots of them.

[fuzzah]

Further testing:

1. Make constructors empty -> same issue.
2. Remove definition of constructors altogether -> same issue.
3. Remove constructors, make the parse method static -> the issue disappears.

The problem is: the actual program I wish to fuzz contains hundreds of constructors and the methods are non-static.

Maybe there's some way to skip all constructors in the sharpfuzz tool?

[fuzzah]

I solved the problem!

Turns out, there's a strict rule: every single bit of instrumented code should be called from Fuzzer.Run/Fuzzer.OutOfProcess.Run, even if you just create objects that don't even depend on the fuzzed stream/string.
Coming from AFL++ and C/C++ fuzzing world with persistence mode, I tried to optimize object creation and moved it out of the fuzzing loop.

So, this code is invalid and will break assemblies after instrumenting them:

public static void Main(string[] args)
{
    Point p = new Point(20, 30);
    Parser parser = new Parser(p, new List<int> { 1, 2, 3, 4 });

    Fuzzer.OutOfProcess.Run(data =>
    {
        parser.parse(data);
    });
}

And this is totally fine:

public static void Main(string[] args)
{
    Fuzzer.OutOfProcess.Run(data =>
    {
        Point p = new Point(20, 30);
        Parser parser = new Parser(p, new List<int> { 1, 2, 3, 4 });

        parser.parse(data);
    });
}

It wasn't obvious to me that SharpFuzz has this limitation, and the exception thrown was really obscure. Furthermore, the limitation is not mentioned in the docs :(

Leaving the issue open for maintainers to decide whether this needs docs / exception fixing.

[Metalnem]

Hi @fuzzah!

I'll be rewriting the README file soon, so I'll mention this limitation in the new version.

In the meantime, I think this pattern might help you to avoid expensive object creation:

MyClass expensive = null;

Fuzzer.Run(stream => {
  if(expensive == null) {
    expensive = new MyClass();
  }
});

[tboby]

While that pattern does help with avoiding expensive work, would I be right in guessing it confuses afl-fuzz's stability tracking considerably?

I initialise some codecs on first run and I'm seeing my stability at <50%. I wonder how much time afl-fuzz spends trying to assess this stability.

Is there a way to have explicit init code that runs without tracing?