Re: INFO: task hung in fanotify_handle_event

[Dmitry Vyukov]

On Mon, Oct 15, 2018 at 2:45 PM, Jan Kara <jack@xxxxxxx> wrote:
> Hi Dmirty!
>
> On Mon 15-10-18 14:29:14, Dmitry Vyukov wrote:
>> On Mon, Oct 15, 2018 at 2:15 PM, Jan Kara <jack@xxxxxxx> wrote:
>> > Hello,
>> >
>> > On Mon 15-10-18 04:32:02, syzbot wrote:
>> >> syzbot found the following crash on:
>> >>
>> >> HEAD commit:    90ad18418c2d Merge git://git.kernel.org/pub/scm/linux/kern..
>> >> git tree:       upstream
>> >> console output: https://syzkaller.appspot.com/x/log.txt?x=17f1776e400000
>> >> kernel config:  https://syzkaller.appspot.com/x/.config?x=88e9a8a39dc0be2d
>> >> dashboard link: https://syzkaller.appspot.com/bug?extid=29143581b0ded3213e99
>> >> compiler:       gcc (GCC) 8.0.1 20180413 (experimental)
>> >> syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=123459d6400000
>> >>
>> >> IMPORTANT: if you fix the bug, please add the following tag to the commit:
>> >> Reported-by: syzbot+29143581b0ded3213e99@xxxxxxxxxxxxxxxxxxxxxxxxx
>> >
>> > Syzbot has apparently generated fanotify watch for FAN_OPEN_PERM event and
>> > then the process got stuck waiting for userspace to respond to that event -
>> > which never happened. So everything works as designed here - the process
>> > placing FAN_OPEN_PERM mark is responsible for replying to the generated
>> > events as all opens hang waiting for responses. That's why the
>> > functionality is behind CAP_SYS_ADMIN after all... Could we fix syzbot to
>> > actually generate replies for these events?
>>
>> Is there a reliable way to kill such processes?
>> Or admins are never supposed to kill any root processes and have not
>> bugs whatsoever? :)
>
> Currently the wait is not killable but yes, we want to make it killable
> exactly because of userspace bugs :). But it is non-trivial because
> currently the waker has also other responsibilities and all that stuff has
> to be cleaned up when handling killed wait. Konstantin Khlebnikov was
> working on that so I might need to prod him.
>
>> syzkaller probably capable of generating replies in some cases, but
>> unfortunately it can't work this way. It's practically not possible to
>> ensure that it will always generate a proper reply and it will be
>> actually delivered and the process won't be killed in the middle, or
>> another thread won't crash or call exit_group concurrently, etc. The
>> thing either needs to be reliable, work without any but's and be
>> reliably killable, or it's not suitable for stress testing.
>> If there is no reliable way to kill it, I think we need to disable
>> FAN_OPEN_PERM entirely.
>
> Understood. Then just disable FAN_OPEN_PERM & FAN_ACCESS_PERM for now.


Disabled FAN_OPEN_PERM & FAN_ACCESS_PERM for now:
https://github.com/google/syzkaller/commit/6ce17935cb99fa11aaa2f2d1889261da6b298013


#syz invalid