* Re: KASAN: use-after-free Read in blkdev_get [not found] <000000000000e59aab056e8873ae@google.com> @ 2019-11-24 19:07 ` syzbot 2019-11-24 19:30 ` Al Viro 0 siblings, 1 reply; 7+ messages in thread From: syzbot @ 2019-11-24 19:07 UTC (permalink / raw) To: cmetcalf, coreteam, davem, dvyukov, gang.chen.5i5j, kaber, kadlec, linux-fsdevel, linux-kernel, netdev, netfilter-devel, pablo, syzkaller-bugs, viro syzbot has bisected this bug to: commit 77ef8f5177599efd0cedeb52c1950c1bd73fa5e3 Author: Chris Metcalf <cmetcalf@ezchip.com> Date: Mon Jan 25 20:05:34 2016 +0000 tile kgdb: fix bug in copy to gdb regs, and optimize memset bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=1131bc0ee00000 start commit: f5b7769e Revert "debugfs: inode: debugfs_create_dir uses m.. git tree: upstream final crash: https://syzkaller.appspot.com/x/report.txt?x=1331bc0ee00000 console output: https://syzkaller.appspot.com/x/log.txt?x=1531bc0ee00000 kernel config: https://syzkaller.appspot.com/x/.config?x=709f8187af941e84 dashboard link: https://syzkaller.appspot.com/bug?extid=eaeb616d85c9a0afec7d syz repro: https://syzkaller.appspot.com/x/repro.syz?x=177f898f800000 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=147eb85f800000 Reported-by: syzbot+eaeb616d85c9a0afec7d@syzkaller.appspotmail.com Fixes: 77ef8f517759 ("tile kgdb: fix bug in copy to gdb regs, and optimize memset") For information about bisection process see: https://goo.gl/tpsmEJ#bisection ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: KASAN: use-after-free Read in blkdev_get 2019-11-24 19:07 ` KASAN: use-after-free Read in blkdev_get syzbot @ 2019-11-24 19:30 ` Al Viro 2019-11-30 11:06 ` Duncan Roe 0 siblings, 1 reply; 7+ messages in thread From: Al Viro @ 2019-11-24 19:30 UTC (permalink / raw) To: syzbot Cc: cmetcalf, coreteam, davem, dvyukov, gang.chen.5i5j, kaber, kadlec, linux-fsdevel, linux-kernel, netdev, netfilter-devel, pablo, syzkaller-bugs On Sun, Nov 24, 2019 at 11:07:00AM -0800, syzbot wrote: > syzbot has bisected this bug to: > > commit 77ef8f5177599efd0cedeb52c1950c1bd73fa5e3 > Author: Chris Metcalf <cmetcalf@ezchip.com> > Date: Mon Jan 25 20:05:34 2016 +0000 > > tile kgdb: fix bug in copy to gdb regs, and optimize memset > > bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=1131bc0ee00000 > start commit: f5b7769e Revert "debugfs: inode: debugfs_create_dir uses m.. > git tree: upstream > final crash: https://syzkaller.appspot.com/x/report.txt?x=1331bc0ee00000 > console output: https://syzkaller.appspot.com/x/log.txt?x=1531bc0ee00000 > kernel config: https://syzkaller.appspot.com/x/.config?x=709f8187af941e84 > dashboard link: https://syzkaller.appspot.com/bug?extid=eaeb616d85c9a0afec7d > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=177f898f800000 > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=147eb85f800000 > > Reported-by: syzbot+eaeb616d85c9a0afec7d@syzkaller.appspotmail.com > Fixes: 77ef8f517759 ("tile kgdb: fix bug in copy to gdb regs, and optimize > memset") > > For information about bisection process see: https://goo.gl/tpsmEJ#bisection Seriously? How can the commit in question (limited to arch/tile/kernel/kgdb.c) possibly affect a bug that manages to produce a crash report with RSP: 0018:ffffffff82e03eb8 EFLAGS: 00000282 RAX: 0000000000000000 RBX: ffffffff82e00000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffffff81088779 RBP: ffffffff82e03eb8 R08: 0000000000000000 R09: 0000000000000001 R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000 R13: 0000000000000000 R14: 0000000000000000 R15: ffffffff82e00000 FS: 0000000000000000(0000) GS:ffff88021fc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000c420447ff8 CR3: 0000000213184000 CR4: 00000000001406f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 in it? Unless something very odd has happened to tile, this crash has been observed on 64bit x86; the names of registers alone are enough to be certain of that. And the binaries produced by an x86 build should not be affected by any changes in arch/tile; not unless something is very wrong with the build system. It's not even that this commit has fixed an earlier bug that used to mask the one manifested here - it really should have had zero impact on x86 builds, period. So I'm sorry, but I'm calling bullshit. Something's quite wrong with the bot - either its build system or the bisection process. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: KASAN: use-after-free Read in blkdev_get 2019-11-24 19:30 ` Al Viro @ 2019-11-30 11:06 ` Duncan Roe 2019-11-30 15:53 ` Dmitry Vyukov 0 siblings, 1 reply; 7+ messages in thread From: Duncan Roe @ 2019-11-30 11:06 UTC (permalink / raw) To: Al Viro Cc: cmetcalf, coreteam, davem, dvyukov, gang.chen.5i5j, kaber, kadlec, linux-fsdevel, linux-kernel, netdev, netfilter-devel, pablo, syzkaller-bugs On Sun, Nov 24, 2019 at 07:30:35PM +0000, Al Viro wrote: > On Sun, Nov 24, 2019 at 11:07:00AM -0800, syzbot wrote: > > syzbot has bisected this bug to: > > > > commit 77ef8f5177599efd0cedeb52c1950c1bd73fa5e3 > > Author: Chris Metcalf <cmetcalf@ezchip.com> > > Date: Mon Jan 25 20:05:34 2016 +0000 > > > > tile kgdb: fix bug in copy to gdb regs, and optimize memset > > > > bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=1131bc0ee00000 > > start commit: f5b7769e Revert "debugfs: inode: debugfs_create_dir uses m.. > > git tree: upstream > > final crash: https://syzkaller.appspot.com/x/report.txt?x=1331bc0ee00000 > > console output: https://syzkaller.appspot.com/x/log.txt?x=1531bc0ee00000 > > kernel config: https://syzkaller.appspot.com/x/.config?x=709f8187af941e84 > > dashboard link: https://syzkaller.appspot.com/bug?extid=eaeb616d85c9a0afec7d > > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=177f898f800000 > > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=147eb85f800000 > > > > Reported-by: syzbot+eaeb616d85c9a0afec7d@syzkaller.appspotmail.com > > Fixes: 77ef8f517759 ("tile kgdb: fix bug in copy to gdb regs, and optimize > > memset") > > > > For information about bisection process see: https://goo.gl/tpsmEJ#bisection > > Seriously? How can the commit in question (limited to arch/tile/kernel/kgdb.c) > possibly affect a bug that manages to produce a crash report with > RSP: 0018:ffffffff82e03eb8 EFLAGS: 00000282 > RAX: 0000000000000000 RBX: ffffffff82e00000 RCX: 0000000000000000 > RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffffff81088779 > RBP: ffffffff82e03eb8 R08: 0000000000000000 R09: 0000000000000001 > R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000 > R13: 0000000000000000 R14: 0000000000000000 R15: ffffffff82e00000 > FS: 0000000000000000(0000) GS:ffff88021fc00000(0000) knlGS:0000000000000000 > CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > CR2: 000000c420447ff8 CR3: 0000000213184000 CR4: 00000000001406f0 > DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 > DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 > in it? Unless something very odd has happened to tile, this crash has > been observed on 64bit x86; the names of registers alone are enough > to be certain of that. > > And the binaries produced by an x86 build should not be affected by any > changes in arch/tile; not unless something is very wrong with the build > system. It's not even that this commit has fixed an earlier bug that > used to mask the one manifested here - it really should have had zero > impact on x86 builds, period. > > So I'm sorry, but I'm calling bullshit. Something's quite wrong with > the bot - either its build system or the bisection process. The acid test would be: does reverting that commit make the problem go away? See, for example, https://bugzilla.kernel.org/show_bug.cgi?id=203935 Cheers ... Duncan. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: KASAN: use-after-free Read in blkdev_get 2019-11-30 11:06 ` Duncan Roe @ 2019-11-30 15:53 ` Dmitry Vyukov 2019-12-01 0:04 ` Duncan Roe 0 siblings, 1 reply; 7+ messages in thread From: Dmitry Vyukov @ 2019-11-30 15:53 UTC (permalink / raw) To: Al Viro, Chris Metcalf, coreteam, David Miller, Dmitry Vyukov, Chen Gang, Patrick McHardy, Jozsef Kadlecsik, linux-fsdevel, LKML, netdev, NetFilter, Pablo Neira Ayuso, syzkaller-bugs On Sat, Nov 30, 2019 at 12:06 PM Duncan Roe <duncan_roe@optusnet.com.au> wrote: > > > syzbot has bisected this bug to: > > > > > > commit 77ef8f5177599efd0cedeb52c1950c1bd73fa5e3 > > > Author: Chris Metcalf <cmetcalf@ezchip.com> > > > Date: Mon Jan 25 20:05:34 2016 +0000 > > > > > > tile kgdb: fix bug in copy to gdb regs, and optimize memset > > > > > > bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=1131bc0ee00000 > > > start commit: f5b7769e Revert "debugfs: inode: debugfs_create_dir uses m.. > > > git tree: upstream > > > final crash: https://syzkaller.appspot.com/x/report.txt?x=1331bc0ee00000 > > > console output: https://syzkaller.appspot.com/x/log.txt?x=1531bc0ee00000 > > > kernel config: https://syzkaller.appspot.com/x/.config?x=709f8187af941e84 > > > dashboard link: https://syzkaller.appspot.com/bug?extid=eaeb616d85c9a0afec7d > > > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=177f898f800000 > > > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=147eb85f800000 > > > > > > Reported-by: syzbot+eaeb616d85c9a0afec7d@syzkaller.appspotmail.com > > > Fixes: 77ef8f517759 ("tile kgdb: fix bug in copy to gdb regs, and optimize > > > memset") > > > > > > For information about bisection process see: https://goo.gl/tpsmEJ#bisection > > > > Seriously? How can the commit in question (limited to arch/tile/kernel/kgdb.c) > > possibly affect a bug that manages to produce a crash report with > > RSP: 0018:ffffffff82e03eb8 EFLAGS: 00000282 > > RAX: 0000000000000000 RBX: ffffffff82e00000 RCX: 0000000000000000 > > RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffffff81088779 > > RBP: ffffffff82e03eb8 R08: 0000000000000000 R09: 0000000000000001 > > R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000 > > R13: 0000000000000000 R14: 0000000000000000 R15: ffffffff82e00000 > > FS: 0000000000000000(0000) GS:ffff88021fc00000(0000) knlGS:0000000000000000 > > CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > > CR2: 000000c420447ff8 CR3: 0000000213184000 CR4: 00000000001406f0 > > DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 > > DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 > > in it? Unless something very odd has happened to tile, this crash has > > been observed on 64bit x86; the names of registers alone are enough > > to be certain of that. > > > > And the binaries produced by an x86 build should not be affected by any > > changes in arch/tile; not unless something is very wrong with the build > > system. It's not even that this commit has fixed an earlier bug that > > used to mask the one manifested here - it really should have had zero > > impact on x86 builds, period. > > > > So I'm sorry, but I'm calling bullshit. Something's quite wrong with > > the bot - either its build system or the bisection process. > > The acid test would be: does reverting that commit make the problem go away? > > See, for example, https://bugzilla.kernel.org/show_bug.cgi?id=203935 > > Cheers ... Duncan. This is done as part of any bisection by definition, right? The test was done on the previous commit (effectively this one reverted) and no crash was observed. Otherwise bisection would have been pointed to a different commit. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: KASAN: use-after-free Read in blkdev_get 2019-11-30 15:53 ` Dmitry Vyukov @ 2019-12-01 0:04 ` Duncan Roe 2019-12-02 6:47 ` Dmitry Vyukov 0 siblings, 1 reply; 7+ messages in thread From: Duncan Roe @ 2019-12-01 0:04 UTC (permalink / raw) To: Dmitry Vyukov Cc: Al Viro, Chris Metcalf, coreteam, David Miller, Chen Gang, Patrick McHardy, Jozsef Kadlecsik, linux-fsdevel, LKML, netdev, NetFilter, Pablo Neira Ayuso, syzkaller-bugs On Sat, Nov 30, 2019 at 04:53:12PM +0100, Dmitry Vyukov wrote: > On Sat, Nov 30, 2019 at 12:06 PM Duncan Roe <duncan_roe@optusnet.com.au> wrote: > > > > syzbot has bisected this bug to: > > > > > > > > commit 77ef8f5177599efd0cedeb52c1950c1bd73fa5e3 > > > > Author: Chris Metcalf <cmetcalf@ezchip.com> > > > > Date: Mon Jan 25 20:05:34 2016 +0000 > > > > > > > > tile kgdb: fix bug in copy to gdb regs, and optimize memset > > > > > > > > bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=1131bc0ee00000 > > > > start commit: f5b7769e Revert "debugfs: inode: debugfs_create_dir uses m.. > > > > git tree: upstream > > > > final crash: https://syzkaller.appspot.com/x/report.txt?x=1331bc0ee00000 > > > > console output: https://syzkaller.appspot.com/x/log.txt?x=1531bc0ee00000 > > > > kernel config: https://syzkaller.appspot.com/x/.config?x=709f8187af941e84 > > > > dashboard link: https://syzkaller.appspot.com/bug?extid=eaeb616d85c9a0afec7d > > > > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=177f898f800000 > > > > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=147eb85f800000 > > > > > > > > Reported-by: syzbot+eaeb616d85c9a0afec7d@syzkaller.appspotmail.com > > > > Fixes: 77ef8f517759 ("tile kgdb: fix bug in copy to gdb regs, and optimize > > > > memset") > > > > > > > > For information about bisection process see: https://goo.gl/tpsmEJ#bisection > > > > > > Seriously? How can the commit in question (limited to arch/tile/kernel/kgdb.c) > > > possibly affect a bug that manages to produce a crash report with > > > RSP: 0018:ffffffff82e03eb8 EFLAGS: 00000282 > > > RAX: 0000000000000000 RBX: ffffffff82e00000 RCX: 0000000000000000 > > > RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffffff81088779 > > > RBP: ffffffff82e03eb8 R08: 0000000000000000 R09: 0000000000000001 > > > R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000 > > > R13: 0000000000000000 R14: 0000000000000000 R15: ffffffff82e00000 > > > FS: 0000000000000000(0000) GS:ffff88021fc00000(0000) knlGS:0000000000000000 > > > CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > > > CR2: 000000c420447ff8 CR3: 0000000213184000 CR4: 00000000001406f0 > > > DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 > > > DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 > > > in it? Unless something very odd has happened to tile, this crash has > > > been observed on 64bit x86; the names of registers alone are enough > > > to be certain of that. > > > > > > And the binaries produced by an x86 build should not be affected by any > > > changes in arch/tile; not unless something is very wrong with the build > > > system. It's not even that this commit has fixed an earlier bug that > > > used to mask the one manifested here - it really should have had zero > > > impact on x86 builds, period. > > > > > > So I'm sorry, but I'm calling bullshit. Something's quite wrong with > > > the bot - either its build system or the bisection process. > > > > The acid test would be: does reverting that commit make the problem go away? > > > > See, for example, https://bugzilla.kernel.org/show_bug.cgi?id=203935 > > > > Cheers ... Duncan. > > This is done as part of any bisection by definition, right? The test > was done on the previous commit (effectively this one reverted) and no > crash was observed. Otherwise bisection would have been pointed to a > different commit. > Agree that's what bisecting does. What I had in mind was to make a patch to remove the identified commit, and apply that to the most recent revision possible. Then see if that makes the problem go away. However when I look at my clone of git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git and compare 77ef8f5177 with the previous commit a7d1357664, "git diff --stat" shows > 745 files changed, 8192 insertions(+), 15408 deletions(-) The last few lines from a grep of "arch" are: > arch/s390/oprofile/backtrace.c | 8 +- > arch/tile/kernel/kgdb.c | 8 +- > arch/x86/Kconfig | 5 +- > arch/x86/include/asm/livepatch.h | 2 +- > arch/x86/include/asm/processor.h | 2 +- > arch/x86/kernel/cpu/perf_event_amd_uncore.c | 2 + > arch/x86/lib/copy_user_64.S | 142 ++- > arch/x86/mm/fault.c | 15 +- > arch/x86/mm/gup.c | 2 +- > arch/x86/mm/numa.c | 2 +- Enough said? Cheers ... Duncan. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: KASAN: use-after-free Read in blkdev_get 2019-12-01 0:04 ` Duncan Roe @ 2019-12-02 6:47 ` Dmitry Vyukov 2019-12-02 9:31 ` Duncan Roe 0 siblings, 1 reply; 7+ messages in thread From: Dmitry Vyukov @ 2019-12-02 6:47 UTC (permalink / raw) To: Dmitry Vyukov, Al Viro, Chris Metcalf, coreteam, David Miller, Chen Gang, Patrick McHardy, Jozsef Kadlecsik, linux-fsdevel, LKML, netdev, NetFilter, Pablo Neira Ayuso, syzkaller-bugs On Sun, Dec 1, 2019 at 1:04 AM Duncan Roe <duncan_roe@optusnet.com.au> wrote: > > On Sat, Nov 30, 2019 at 04:53:12PM +0100, Dmitry Vyukov wrote: > > On Sat, Nov 30, 2019 at 12:06 PM Duncan Roe <duncan_roe@optusnet.com.au> wrote: > > > > > syzbot has bisected this bug to: > > > > > > > > > > commit 77ef8f5177599efd0cedeb52c1950c1bd73fa5e3 > > > > > Author: Chris Metcalf <cmetcalf@ezchip.com> > > > > > Date: Mon Jan 25 20:05:34 2016 +0000 > > > > > > > > > > tile kgdb: fix bug in copy to gdb regs, and optimize memset > > > > > > > > > > bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=1131bc0ee00000 > > > > > start commit: f5b7769e Revert "debugfs: inode: debugfs_create_dir uses m.. > > > > > git tree: upstream > > > > > final crash: https://syzkaller.appspot.com/x/report.txt?x=1331bc0ee00000 > > > > > console output: https://syzkaller.appspot.com/x/log.txt?x=1531bc0ee00000 > > > > > kernel config: https://syzkaller.appspot.com/x/.config?x=709f8187af941e84 > > > > > dashboard link: https://syzkaller.appspot.com/bug?extid=eaeb616d85c9a0afec7d > > > > > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=177f898f800000 > > > > > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=147eb85f800000 > > > > > > > > > > Reported-by: syzbot+eaeb616d85c9a0afec7d@syzkaller.appspotmail.com > > > > > Fixes: 77ef8f517759 ("tile kgdb: fix bug in copy to gdb regs, and optimize > > > > > memset") > > > > > > > > > > For information about bisection process see: https://goo.gl/tpsmEJ#bisection > > > > > > > > Seriously? How can the commit in question (limited to arch/tile/kernel/kgdb.c) > > > > possibly affect a bug that manages to produce a crash report with > > > > RSP: 0018:ffffffff82e03eb8 EFLAGS: 00000282 > > > > RAX: 0000000000000000 RBX: ffffffff82e00000 RCX: 0000000000000000 > > > > RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffffff81088779 > > > > RBP: ffffffff82e03eb8 R08: 0000000000000000 R09: 0000000000000001 > > > > R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000 > > > > R13: 0000000000000000 R14: 0000000000000000 R15: ffffffff82e00000 > > > > FS: 0000000000000000(0000) GS:ffff88021fc00000(0000) knlGS:0000000000000000 > > > > CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > > > > CR2: 000000c420447ff8 CR3: 0000000213184000 CR4: 00000000001406f0 > > > > DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 > > > > DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 > > > > in it? Unless something very odd has happened to tile, this crash has > > > > been observed on 64bit x86; the names of registers alone are enough > > > > to be certain of that. > > > > > > > > And the binaries produced by an x86 build should not be affected by any > > > > changes in arch/tile; not unless something is very wrong with the build > > > > system. It's not even that this commit has fixed an earlier bug that > > > > used to mask the one manifested here - it really should have had zero > > > > impact on x86 builds, period. > > > > > > > > So I'm sorry, but I'm calling bullshit. Something's quite wrong with > > > > the bot - either its build system or the bisection process. > > > > > > The acid test would be: does reverting that commit make the problem go away? > > > > > > See, for example, https://bugzilla.kernel.org/show_bug.cgi?id=203935 > > > > > > Cheers ... Duncan. > > > > This is done as part of any bisection by definition, right? The test > > was done on the previous commit (effectively this one reverted) and no > > crash was observed. Otherwise bisection would have been pointed to a > > different commit. > > > Agree that's what bisecting does. What I had in mind was to make a patch to > remove the identified commit, and apply that to the most recent revision > possible. Then see if that makes the problem go away. I wonder in what percent of cases: 1. It gives signal different from reverting the commit in place. 2. The revert can be cleanly applied to head. 3. The revert does not introduce other bugs. For this to be worth doing, all these 3 should be reasonably high. I can imagine 3 may be high (?), but I am not sure about 1 and 2. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: KASAN: use-after-free Read in blkdev_get 2019-12-02 6:47 ` Dmitry Vyukov @ 2019-12-02 9:31 ` Duncan Roe 0 siblings, 0 replies; 7+ messages in thread From: Duncan Roe @ 2019-12-02 9:31 UTC (permalink / raw) To: Dmitry Vyukov Cc: Al Viro, Chris Metcalf, coreteam, David Miller, Chen Gang, Patrick McHardy, Jozsef Kadlecsik, linux-fsdevel, LKML, netdev, NetFilter, Pablo Neira Ayuso, syzkaller-bugs On Mon, Dec 02, 2019 at 07:47:11AM +0100, Dmitry Vyukov wrote: > On Sun, Dec 1, 2019 at 1:04 AM Duncan Roe <duncan_roe@optusnet.com.au> wrote: > > > > On Sat, Nov 30, 2019 at 04:53:12PM +0100, Dmitry Vyukov wrote: > > > On Sat, Nov 30, 2019 at 12:06 PM Duncan Roe <duncan_roe@optusnet.com.au> wrote: > > > > > > syzbot has bisected this bug to: > > > > > > > > > > > > commit 77ef8f5177599efd0cedeb52c1950c1bd73fa5e3 > > > > > > Author: Chris Metcalf <cmetcalf@ezchip.com> > > > > > > Date: Mon Jan 25 20:05:34 2016 +0000 > > > > > > > > > > > > tile kgdb: fix bug in copy to gdb regs, and optimize memset > > > > > > > > > > > > bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=1131bc0ee00000 > > > > > > start commit: f5b7769e Revert "debugfs: inode: debugfs_create_dir uses m.. > > > > > > git tree: upstream > > > > > > final crash: https://syzkaller.appspot.com/x/report.txt?x=1331bc0ee00000 > > > > > > console output: https://syzkaller.appspot.com/x/log.txt?x=1531bc0ee00000 > > > > > > kernel config: https://syzkaller.appspot.com/x/.config?x=709f8187af941e84 > > > > > > dashboard link: https://syzkaller.appspot.com/bug?extid=eaeb616d85c9a0afec7d > > > > > > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=177f898f800000 > > > > > > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=147eb85f800000 > > > > > > > > > > > > Reported-by: syzbot+eaeb616d85c9a0afec7d@syzkaller.appspotmail.com > > > > > > Fixes: 77ef8f517759 ("tile kgdb: fix bug in copy to gdb regs, and optimize > > > > > > memset") > > > > > > > > > > > > For information about bisection process see: https://goo.gl/tpsmEJ#bisection > > > > > > > > > > Seriously? How can the commit in question (limited to arch/tile/kernel/kgdb.c) > > > > > possibly affect a bug that manages to produce a crash report with > > > > > RSP: 0018:ffffffff82e03eb8 EFLAGS: 00000282 > > > > > RAX: 0000000000000000 RBX: ffffffff82e00000 RCX: 0000000000000000 > > > > > RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffffff81088779 > > > > > RBP: ffffffff82e03eb8 R08: 0000000000000000 R09: 0000000000000001 > > > > > R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000 > > > > > R13: 0000000000000000 R14: 0000000000000000 R15: ffffffff82e00000 > > > > > FS: 0000000000000000(0000) GS:ffff88021fc00000(0000) knlGS:0000000000000000 > > > > > CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > > > > > CR2: 000000c420447ff8 CR3: 0000000213184000 CR4: 00000000001406f0 > > > > > DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 > > > > > DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 > > > > > in it? Unless something very odd has happened to tile, this crash has > > > > > been observed on 64bit x86; the names of registers alone are enough > > > > > to be certain of that. > > > > > > > > > > And the binaries produced by an x86 build should not be affected by any > > > > > changes in arch/tile; not unless something is very wrong with the build > > > > > system. It's not even that this commit has fixed an earlier bug that > > > > > used to mask the one manifested here - it really should have had zero > > > > > impact on x86 builds, period. > > > > > > > > > > So I'm sorry, but I'm calling bullshit. Something's quite wrong with > > > > > the bot - either its build system or the bisection process. > > > > > > > > The acid test would be: does reverting that commit make the problem go away? > > > > > > > > See, for example, https://bugzilla.kernel.org/show_bug.cgi?id=203935 > > > > > > > > Cheers ... Duncan. > > > > > > This is done as part of any bisection by definition, right? The test > > > was done on the previous commit (effectively this one reverted) and no > > > crash was observed. Otherwise bisection would have been pointed to a > > > different commit. > > > > > Agree that's what bisecting does. What I had in mind was to make a patch to > > remove the identified commit, and apply that to the most recent revision > > possible. Then see if that makes the problem go away. > > I wonder in what percent of cases: > 1. It gives signal different from reverting the commit in place. > 2. The revert can be cleanly applied to head. > 3. The revert does not introduce other bugs. > > For this to be worth doing, all these 3 should be reasonably high. I > can imagine 3 may be high (?), but I am not sure about 1 and 2. The whole arch/tile directory no longer exists, so the patch cannot be applied. If I had realised that earlier, I would not have posted at all. Sorry for the noise. ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2019-12-02 9:32 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <000000000000e59aab056e8873ae@google.com>
2019-11-24 19:07 ` KASAN: use-after-free Read in blkdev_get syzbot
2019-11-24 19:30 ` Al Viro
2019-11-30 11:06 ` Duncan Roe
2019-11-30 15:53 ` Dmitry Vyukov
2019-12-01 0:04 ` Duncan Roe
2019-12-02 6:47 ` Dmitry Vyukov
2019-12-02 9:31 ` Duncan Roe
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).