Added fuzzer for msgpack

[AdamKorcz]

A couple of notes on this fuzzer:

1: It runs out of memory fairly quickly (about 20-30 seconds). To me it looks like everything is freed as it should be, but if that is not the case, I will appreciate any observations.

2: There are 2 assertions that make the fuzzer stop altogether. The one is line 1304:

libucl/src/ucl_msgpack.c

Lines 1301 to 1306 in e03e0bc

	/* Rewind to the top level container */
	ucl_msgpack_get_next_container (parser);
	assert (parser->stack == NULL);
	return true;

If you see a way to not trigger it, please let me know. We could free parser->stack manually and add a return statement just above it to not stop the fuzzer.

The second is on line 1047:

libucl/src/ucl_msgpack.c

Lines 1033 to 1049 in e03e0bc

	switch (obj_parser->len) {
	case 1:
	len = *p;
	break;
	case 2:
	len = FROM_BE16 (*(uint16_t *)p);
	break;
	case 4:
	len = FROM_BE32 (*(uint32_t *)p);
	break;
	case 8:
	len = FROM_BE64 (*(uint64_t *)p);
	break;
	default:
	assert (0);
	break;
	}

Depending on what the logic is here, it might not be able to avoid it. If you have a suggestion to not abort here, do let me know.

In either case, we don’t need to change the code in the repository. We would make a temporary fix when running the fuzzers. Nevertheless, I would like to be sure that we don’t divert from the logic of the application.

It would be great if we could find a solution, as the fuzzer does find an off-by-one in ucl_msgpack.c, and it covers a large part of the ucl_msgpack.c code.

[vstakhov]

Asserts in a library are bad. It is my bad specifically in this case. I'll look into that.

[vstakhov]

I have fixed these two asserts. I have not checked memory usage yet.

[vstakhov]

Here is your leak btw. Why do you create this object that never got used/accessed or freed?

[vstakhov]

Ok, I have found your leak source.

[AdamKorcz]

Great catch with the object, thanks a lot!

Awesome with the two assertions. The fuzzer aborts from more assertions in ucl_msgpack. From a fuzzing-point-of-view, it would be best to get rid of all of them. I will be glad to continue the work you did with the assertions today and write the rest into if-statements that throw an ucl_create_err in case they fail. Are you open to such an improvement to ucl_msgpack?

[vstakhov]

Yes, sure. Asserts should not happen because of the bad input - it should merely be a sign of library misuse. Msgpack part of libucl is not very mature tbh...