does syzkaller always follow syscall description when mutate syscall arguments?

[David Lee]

Hi,

I recently looked into syzkaller and have one question about the argument mutation mechanism of syzkaller: does syzkaller always follow the type definition in syscall description? Or syzkaller will also choose to randomly mutate syscall arguments regardless of syscall description? 

I noticed that for some syzlang program, the arguments has the clear type information, such as "&{{0x12, 0x1, 0x300, 0x3c, 0x3b, 0xa8, 0x20, 0x424, 0xcf30, 0xcff0, 0x1, 0x2, 0x3, 0x1, [{{0x9, 0x2, 0x38, 0x1, 0x2, 0x7, 0x90, 0x75, [{{0x9, 0x4, 0xf0, 0x39, 0x0, 0xb5, 0x9d, 0x1f, 0xe, [@uac_control={{0xa, 0x24, 0x1, 0x5, 0x8}}, @cdc_ncm={{0x5}, {0x5, 0x24, 0x0, 0x3}, {0xd, 0x24, 0xf, 0x1, 0x0, 0x1, 0x2, 0x8}, {0x6, 0x24, 0x1a, 0x4, 0x12}}]}}]}}]}}".

When looking its corresponding syscall description, people can know the values of the different nested fields of this argument.

But for others, it can just be "@ANYBLOB="140000001000010000000000000000000000000a28000000000a0101000000005e1affd5020000000900010073797a300000000008000240000000032c000000030a01030000e6ff00000000020000000900010073797a30000000000900030073797a320000000014000000110001"]". People can not know the value of the nested fileds within this argument.

For those ANYBLOB cases, does it also follow the syscall description to mutate the syscall arguments or just totally random mutate its input? Or it is just a different way to show the argument?

Thanks.

[Alexander Potapenko]

Hi David,

ANYBLOB is mutated randomly without exactly following the underlying structure.

In theory, this can unlock certain interesting mutations, but it makes the programs quite hard to reason about.

We've recently introduced the no_squash attribute that prevents this behavior for certain syscalls, see e.g. https://github.com/google/syzkaller/blob/master/sys/linux/dev_kvm_amd64.txt#L23

Hope this helps.

--
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 visit https://groups.google.com/d/msgid/syzkaller/CAJzqDgZqmGrCV7UtOcdkaWpmSGEztQBt7LOBkKO0XC6cTCTspg%40mail.gmail.com.

--

Alexander Potapenko

Software Engineer

Google Germany GmbH
Erika-Mann-Straße, 33
80636 München

Geschäftsführer: Paul Manicle, Liana Sebastian
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg

[David Lee]

Hi Alexander,

Thanks for your response. I have another question: is there a possibility like parameter which can control the squash to generate random blob without following syscall description? I supposed that the squash behavior should be controlled by a probability to determine if an argument should be squashed.

Also, if an argument is squashed, all of its following mutations should be also random blob without following syscall description. Is my understanding correct? Thanks.

[Aleksandr Nogikh]

On Fri, Nov 21, 2025 at 7:59 PM David Lee <sayni...@gmail.com> wrote:
>
> Hi Alexander,
>
> Thanks for your response. I have another question: is there a possibility like parameter which can control the squash to generate random blob without following syscall description? I supposed that the squash behavior should be controlled by a probability to determine if an argument should be squashed.

Syzkaller has a piece of logic that determines if a type can be
squashed at all, but whether it will actually be squashed is
determined randomly each time we mutate the program.

>
> Also, if an argument is squashed, all of its following mutations should be also random blob without following syscall description. Is my understanding correct? Thanks.

Yes. Once it's squashed, it's just a binary blob.

> To view this discussion visit https://groups.google.com/d/msgid/syzkaller/CAJzqDgYhFtGbjiEVibgdA7c-hT4oUoGcqNvAVVyMmCkJQxUH5g%40mail.gmail.com.