linux-kernel - Re: KASAN: null-ptr-deref Write in io_wq_cancel

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-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 25 Oct 2019 08:35:39 -0600
From:   Jens Axboe <axboe@...nel.dk>
To:     Dmitry Vyukov <dvyukov@...gle.com>,
        syzbot <syzbot+d958a65633ea70280b23@...kaller.appspotmail.com>
Cc:     linux-fsdevel <linux-fsdevel@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>,
        syzkaller-bugs <syzkaller-bugs@...glegroups.com>,
        Al Viro <viro@...iv.linux.org.uk>
Subject: Re: KASAN: null-ptr-deref Write in io_wq_cancel_all

On 10/25/19 7:50 AM, Jens Axboe wrote:
> On 10/25/19 5:58 AM, Dmitry Vyukov wrote:
>> On Fri, Oct 25, 2019 at 1:51 PM syzbot
>> <syzbot+d958a65633ea70280b23@...kaller.appspotmail.com> wrote:
>>>
>>> Hello,
>>>
>>> syzbot found the following crash on:
>>>
>>> HEAD commit:    139c2d13 Add linux-next specific files for 20191025
>>> git tree:       linux-next
>>> console output: https://syzkaller.appspot.com/x/log.txt?x=17ab5a70e00000
>>> kernel config:  https://syzkaller.appspot.com/x/.config?x=28fd7a693df38d29
>>> dashboard link: https://syzkaller.appspot.com/bug?extid=d958a65633ea70280b23
>>> compiler:       gcc (GCC) 9.0.0 20181231 (experimental)
>>>
>>> Unfortunately, I don't have any reproducer for this crash yet.
>>>
>>> IMPORTANT: if you fix the bug, please add the following tag to the commit:
>>> Reported-by: syzbot+d958a65633ea70280b23@...kaller.appspotmail.com
>>
>> +Jens
> 
> Let me know if/when you have a reproducer for this one. I initially thought
> this was a basic NULL pointer check, but it doesn't look like it. I wonder
> if the thread handling the request got a signal, and since it had the
> task file_table with the io_uring fd attached, it's triggering an exit.
> 
> I'll poke at it, but don't immediately see the issue.

Ah, I see it, if we run into work needing to get done as the worker
is exiting, we do that work. But that makes us busy, and we can then
exit the thread without having dropped the mm/files associated with
the original task. I've folded in a fix.

-- 
Jens Axboe