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
| ||
|
Date: Mon, 6 Apr 2020 16:21:18 -0700 From: Andrew Morton <akpm@...ux-foundation.org> To: syzbot <syzbot+b4501d3e966ff59f6090@...kaller.appspotmail.com> Cc: bgeffon@...gle.com, linux-kernel@...r.kernel.org, linux-mm@...ck.org, peterx@...hat.com, syzkaller-bugs@...glegroups.com, torvalds@...ux-foundation.org Subject: Re: KASAN: user-memory-access Read in put_page On Mon, 06 Apr 2020 11:16:13 -0700 syzbot <syzbot+b4501d3e966ff59f6090@...kaller.appspotmail.com> wrote: > Hello, > > syzbot found the following crash on: > > HEAD commit: bef7b2a7 Merge tag 'devicetree-for-5.7' of git://git.kerne.. > git tree: upstream > console output: https://syzkaller.appspot.com/x/log.txt?x=16940efbe00000 > kernel config: https://syzkaller.appspot.com/x/.config?x=f72ba8a207627d60 > dashboard link: https://syzkaller.appspot.com/bug?extid=b4501d3e966ff59f6090 > compiler: clang version 10.0.0 (https://github.com/llvm/llvm-project/ c2443155a0fb245c8f17f2c1c72b6ea391e86e81) > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=15d79efbe00000 > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1705901be00000 > > The bug was bisected to: > > commit 4426e945df588f2878affddf88a51259200f7e29 > Author: Peter Xu <peterx@...hat.com> > Date: Thu Apr 2 04:08:49 2020 +0000 > > mm/gup: allow VM_FAULT_RETRY for multiple times > > bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=1441b1fbe00000 > final crash: https://syzkaller.appspot.com/x/report.txt?x=1641b1fbe00000 > console output: https://syzkaller.appspot.com/x/log.txt?x=1241b1fbe00000 Thanks. This looks like a duplicate of your report syzbot+693dc11fcb53120b5559@...kaller.appspotmail.com ("BUG: unable to handle kernel paging request in kernel_get_mempolicy"). The bisection is believable but I can't spot why 4426e945df58 would have messed up get_user_pages_locked() in this fashion - I've asked Peter to take a look.
Powered by blists - more mailing lists