Re: VIVID/VIMC and media fuzzing

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Dmitry,

On 10/31/18 9:49 AM, Helen Koike wrote:
> Hi Dmitry,
> 
> On 10/31/18 7:46 AM, Hans Verkuil wrote:
>> On 10/30/2018 03:02 PM, Dmitry Vyukov wrote:
>>> Hello Helen and linux-media,
>>>
>>> I've attended your talk "Shifting Media App Development into High
>>> Gear" on OSS Summit last week and approached you with some questions
>>> if/how this can be used for kernel testing. Thanks, turn out to be a
>>> very useful talk!
> 
> Great, I am  glad it was useful :)
> 
>>>
>>> I am working on syzkaller/syzbot, continuous kernel fuzzing system:
>>> https://github.com/google/syzkaller
>>> https://github.com/google/syzkaller/blob/master/docs/syzbot.md
>>> https://syzkaller.appspot.com
>>>
>>> After simply enabling CONFIG_VIDEO_VIMC, CONFIG_VIDEO_VIM2M,
>>> CONFIG_VIDEO_VIVID, CONFIG_VIDEO_VICODEC syzbot has found 8 bugs in
>>> media subsystem in just 24 hours:
>>>
>>> KASAN: use-after-free Read in vb2_mmap
>>> https://groups.google.com/forum/#!msg/syzkaller-bugs/XGGH69jMWQ0/S8vfxgEmCgAJ
>>>
>>> KASAN: use-after-free Write in __vb2_cleanup_fileio
>>> https://groups.google.com/forum/#!msg/syzkaller-bugs/qKKhsZVPo3o/P6AB2of2CQAJ
>>>
>>> WARNING in __vb2_queue_cancel
>>> https://groups.google.com/forum/#!msg/syzkaller-bugs/S29GU_NtfPY/ZvAz8UDtCQAJ
>>>
>>> divide error in vivid_vid_cap_s_dv_timings
>>> https://groups.google.com/forum/#!msg/syzkaller-bugs/GwF5zGBCfyg/wnuWmW_sCQAJ
>>
>> Should be fixed by https://patchwork.linuxtv.org/patch/52641/
>>
>>>
>>> KASAN: use-after-free Read in wake_up_if_idle
>>> https://groups.google.com/forum/#!msg/syzkaller-bugs/aBWb_yV1kiI/sWQO63fkCQAJ
>>>
>>> KASAN: use-after-free Read in __vb2_perform_fileio
>>> https://groups.google.com/forum/#!msg/syzkaller-bugs/MdFCZHz0LUQ/qSK_bFbcCQAJ
>>>
>>> INFO: task hung in vivid_stop_generating_vid_cap
>>> https://groups.google.com/forum/#!msg/syzkaller-bugs/F_KFW6PVyTA/wTBeHLfTCQAJ
>>>
>>> KASAN: null-ptr-deref Write in kthread_stop
>>> https://groups.google.com/forum/#!msg/syzkaller-bugs/u0AGnYvSlf4/fUiyfA_TCQAJ
>>
>> These last two should be fixed by https://patchwork.linuxtv.org/patch/52640/
>>
>> Haven't figured out the others yet (hope to get back to that next week).
>>
>>>
>>> Based on this I think if we put more effort into media fuzzing, it
>>> will be able to find dozens more.
>>
>> Yeah, this is good stuff. Thank you for setting this up.
> 
> Agreed, Dmitry thank you for doing this.
> 
>>
>>>
>>> syzkaller needs descriptions of kernel interfaces to efficiently cover
>>> a subsystem. For example, see:
>>> https://github.com/google/syzkaller/blob/master/sys/linux/uinput.txt
>>> Hopefully you can read it without much explanation, it basically
>>> states that there is that node in /dev and here are ioctls and other
>>> syscalls that are relevant for this device and here are types of
>>> arguments and layout of involved data structures.
>>>
>>> Turned we actually have such descriptions for /dev/video* and /dev/v4l-subdev*:
>>> https://github.com/google/syzkaller/blob/master/sys/linux/video4linux.txt
>>> But we don't have anything for /dev/media*, fuzzer merely knows that
>>> it can open the device:
>>> https://github.com/google/syzkaller/blob/12b38f22c18c6109a5cc1c0238d015eef121b9b7/sys/linux/sys.txt#L479
>>> and then it will just blindly execute completely random workload on
>>> it, e.g. most likely it won't be able to come up with a proper complex
>>> structure layout for some ioctls. And I am actually not completely
>>> sure about completeness and coverage of video4linux.txt descriptions
>>> too as they were contributed by somebody interested in android
>>> testing.
>>
>> A quick look suggests that it is based on the 4.9 videodev2.h, which ain't
>> too bad. There are some differences between the 4.20 videodev2.h and the
>> 4.9, but not too many.
>>
>>>
>>> I wonder if somebody knowledgeable in /dev/media interface be willing
>>> to contribute additional descriptions?
>>
>> We'll have to wait for 4.20-rc1 to be released since there are important
>> additions to the media API. I can probably come up with something, I'm
>> just not sure when I get around to it. Ping me in three weeks time if you
>> haven't heard from me.
>>
>>>
>>> We also have code coverage reports with the coverage fuzzer achieved
>>> so far. Here in the Cover column:
>>> https://syzkaller.appspot.com/#managers
>>> e.g. this one (but note this is a ~80MB html file):
>>> https://storage.googleapis.com/syzkaller/cover/ci-upstream-kasan-gce-root.html
>>> This can be used to assess e.g. v4l coverage. But I don't know what's
>>> coverable in general from syscalls and what's coverable via the stub
>>> drivers in particular. So some expertise from media developers would
>>> be helpful too.
>>
>> The four virtual drivers should give pretty decent coverage of the core
>> code. Are you able to test with a 32-bit syzkaller application on a 64-bit
>> kernel as well? That way the compat32 code is tested.
>>
>>>
>>> Do I understand it correctly that when a process opens /dev/video* or
>>> /dev/media* it gets a private instance of the device? In particular,
>>> if several processes test this in parallel, will they collide? Or they
>>> will stress separate objects?
>>
>> It actually depends on the driver. M2M devices will give you a private
>> instance whenever you open it. Others do not, but you can call most ioctls
>> in parallel. But after calling REQBUFS or CREATE_BUFS the filehandle that
>> called those ioctls becomes owner of the device until the buffers are
>> released. So other filehandles cannot do any streaming operations (EBUSY
>> will be returned).
>>
>>> You also mentioned that one of the devices requires some complex setup
>>> via configfs. Is this interface described somewhere? Do you think it's
>>> more profitable to pre-setup some fixed configuration for each test
>>> process? Or just give the setup interface to fuzzer and let it do
>>> random setup? Or both?
>>
>> That's the vimc driver, but the configfs code isn't in yet.
> 
> I'll try to submit it later this week (with documentation) :)

I submitted the first version at:
https://www.spinics.net/lists/linux-media/msg144244.html
As soon as it is updated we can add it to fuzzer. I believe some
pre-setup/fixed configuration would work.

I don't know much about fuzzer's code, if you could give me some
pointers I can help with that.

Thanks
Helen

> 
>>
>> Regards,
>>
>> 	Hans
>>
>>>
>>> Thanks in advance
>>>
>>
> 
> 
> Thanks
> Helen
> 



[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]

  Powered by Linux