syzkaller not respecting resource requirements?

[Ben Kittner]

I'm running into an issue with what I describe in my syzlang vs what the fuzzer thinks is actually appropriate behavior.

I described a special type of dir_fd resource, a special producer, and a consumer for it:

resource special_fd_dir[fd_dir]

syz_ext_create_special_fd_dir(...) special_fd_dir

execveat$special_fd_dir(special_dir special_fd_dir, file ptr[in, string[string_list]], ...)

However, when I check the corpus for my new syscall I'm seeing the following which doesn't generate any meaningful coverage, since it's not even calling the syscall that generates the resource in the first place (not to mention that it doesn't pull from the provided string list):

```

execveat$special_fd_dir((0xffffffffffffffff, 0x0, 0x0, 0x0, 0x0)

```

Is this expected behavior, am I doing something wrong, or is this a bug?

I can come back with more information too

[Aleksandr Nogikh]

Hi,

That's the expected behavior of the fuzzer -- it will respect the
rules most of the time, but sometimes it intentionally violates them,
e.g. like in this case, where it used a special const value instead of
a valid resource.

If such an input ended up in the corpus, it means it did trigger some
code coverage that distinguished it from the other inputs.

--
Aleksandr

> --
> You received this message because you are subscribed to the Google Groups "syzkaller" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to syzkaller+...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/syzkaller/58cf7385-0aa0-4c46-8c3d-269b3cdb581fn%40googlegroups.com.

[Ben Kittner]

I understand that it doesn't strictly respect the boundaries described, but I guess I would just expect it to try to do things by the rules first. 

At the time, that was the only program in the corpus, and it gave poor coverage. However, once I let it run overnight and it started running things by the rules I set out I started to get good coverage in the expected source files.

I just thought it would prioritize running things by the rules I guess?

[Ben Kittner]

Like normally I see really good recovery of coverage on manager restart, but recently when I look at the early coverage reports for syscalls that should touch specific files and subsystems they're really poor, and drilling down shows me that they're really just using arguments that could never make it past upper level error checking instead of the "guideline" arguments that give good coverage.

[Ben Kittner]

Ok, nevermind, I see: I had changed the function signature to return an inherited resource type with my recent change, so that probably made my existing database invalid I guess? Comparing my existing repo to the one before this change, I can see that repo is able to generate coverage with the unmodified syzcalls.

I'm not seeing any complaints about my corpus being broken though.

Does this mean I need to discard my corpus.db with this change?

[Dmitry Vyukov]

On Thu, 13 Jun 2024 at 22:01, Ben Kittner <benki...@gmail.com> wrote:
>
> Ok, nevermind, I see: I had changed the function signature to return an inherited resource type with my recent change, so that probably made my existing database invalid I guess? Comparing my existing repo to the one before this change, I can see that repo is able to generate coverage with the unmodified syzcalls.
>
> I'm not seeing any complaints about my corpus being broken though.
>
> Does this mean I need to discard my corpus.db with this change?

No, you don't.

> To view this discussion on the web visit https://groups.google.com/d/msgid/syzkaller/0af39b5c-ddf8-4e1e-8be5-1854796157ccn%40googlegroups.com.