syzkaller support for AF_CAN

[Dmitry Vyukov]

On Wed, Jan 10, 2018 at 8:35 PM, Oliver Hartkopp <socketcan@xxxxxxxxxxxx> wrote:
> Hi Dmitry,
>
> I'm the maintainer of the CAN bus networking subsystem in linux/net/can/ and
> I'm following the interesting bugs the syzkaller is posting on netdev
> mailing list.
>
> We already had a CAN issue here:
> https://groups.google.com/forum/#!topic/syzkaller/to2Or4lUrTU
>
> But now CONFIG_CAN seems to be disabled in the recent posts.
> I would be happy if you could also enable CONFIG_CAN and the network layer
> stuff below (RAW/BCM/GW) to see, if it explodes ;-)
>
> No idea whether it makes sense to create virtual CAN interfaces with the
> vcan driver or if it's just enough to enable the CAN network layer?!?

+mailing lists

Hi Oliver,

Sure, we can enable CAN configs if there is active interest in fixing
bugs in this subsystem.
Please provide full set of configs. Is CONFIG_CAN the only one? What
is RAW/BCM/GW?

While you are here I have a counter ask. syzkaller is magic, but not
completely. It needs help to test particular subsystems in 2 ways:
1. It needs descriptions of user<->kernel interfaces to meaningfully
test a subsystem. For example, you can see what we have for SCTP:
https://github.com/google/syzkaller/blob/master/sys/linux/socket_inet_sctp.txt
and generally *.txt files here:
https://github.com/google/syzkaller/tree/master/sys/linux

I see that for AF_CAN we have only
syzkaller$ grep "AF_CAN" sys/linux/*.txt
sys/linux/socket.txt:# TODO: AF_CAN
sys/linux/socket.txt:# TODO: AF_CAN

So I guess it was mostly just able to create an AF_CAN socket, but
wasn't able to progress further. Adding proper descriptions can make
difference between few bugs (I see 4 for net/can here
https://github.com/google/syzkaller/blob/master/docs/linux/found_bugs.md)
and several dozens (yes, that happened with ALSA, AF_KEY and some
other subsystems).

But writing these descriptions requires subsystem expertise, and we
don't have expertise in just any kernel subsystem. You (maintainer of
a particular subsystem) is in the best position to do this. If you add
them to syzkaller, they will be automatically picked up by syzbot.

2. Some subsystems require expertise beyond plain interfaces (e.g.
cgroups, kvm). You are mentioning "virtual CAN interfaces", "vcan
driver", but this says nothing to me. What are these? If proper
testing of this subsystem requires these things, then we need to
ensure that syzkaller is capable of creating them on the fly, or
somehow arrange precreated things. syzkaller also requires as much
isolation between test programs as possible (in particular to be able
to create reproducers). Is creation of virtual CAN interfaces per
test-process feasible/meaningful?

Thanks