linux-kernel - syzkaller support for AF

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <CACT4Y+avEXjEGDEdtnmV3sS=Y463x03PN0RHXeKTtPZkZThSGA@mail.gmail.com>
Date:   Thu, 11 Jan 2018 09:15:22 +0100
From:   Dmitry Vyukov <dvyukov@...gle.com>
To:     Oliver Hartkopp <socketcan@...tkopp.net>
Cc:     syzkaller <syzkaller@...glegroups.com>, mkl@...gutronix.de,
        linux-can@...r.kernel.org, LKML <linux-kernel@...r.kernel.org>
Subject: syzkaller support for AF_CAN

On Wed, Jan 10, 2018 at 8:35 PM, Oliver Hartkopp <socketcan@...tkopp.net> 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