netdev - Re: WARNING in check_flush

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:   Wed, 24 Jan 2018 08:39:26 +0100
From:   Johannes Berg <johannes@...solutions.net>
To:     syzbot <syzbot+41cdaf4232c50e658934@...kaller.appspotmail.com>,
        davem@...emloft.net, linux-kernel@...r.kernel.org,
        linux-wireless@...r.kernel.org, netdev@...r.kernel.org,
        syzkaller-bugs@...glegroups.com
Subject: Re: WARNING in check_flush_dependency

On Mon, 2018-01-22 at 23:39 -0800, syzbot wrote:
> Hello,
> 
> syzbot hit the following crash on upstream commit
> 0d665e7b109d512b7cae3ccef6e8654714887844 (Fri Jan 19 12:49:24 2018 +0000)
> mm, page_vma_mapped: Drop faulty pointer arithmetics in check_pte()
> 
> So far this crash happened 23 times on net-next, upstream.
> C reproducer is attached.
> syzkaller reproducer is attached.
> Raw console output is attached.
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached.
> user-space arch: i386
> 
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+41cdaf4232c50e658934@...kaller.appspotmail.com
> It will help syzbot understand when the bug is fixed. See footer for  
> details.
> If you forward the report, please keep this part and the footer.
> 
> ------------[ cut here ]------------
> workqueue: WQ_MEM_RECLAIM hwsim_wq:destroy_radio is  
> flushing !WQ_MEM_RECLAIM events_highpri:flush_backlog
> WARNING: CPU: 0 PID: 3706 at kernel/workqueue.c:2439  
> check_flush_dependency+0x239/0x380 kernel/workqueue.c:2435
> Kernel panic - not syncing: panic_on_warn set ...

Yeah, we clearly shouldn't have WQ_RECLAIM set on this workqueue...

johannes