linux-kernel - Re: KASAN: use-after-free Read in locks_delete

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]

Message-ID: <c76712278e2d7f5c4c8cfbab687a941bf493b0c6.camel@kernel.org>
Date:   Sat, 17 Nov 2018 08:33:27 -0500
From:   Jeff Layton <jlayton@...nel.org>
To:     Dmitry Vyukov <dvyukov@...gle.com>, NeilBrown <neilb@...e.com>
Cc:     syzbot <syzbot+a4a3d526b4157113ec6a@...kaller.appspotmail.com>,
        Bruce Fields <bfields@...ldses.org>,
        linux-fsdevel <linux-fsdevel@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>,
        syzkaller-bugs@...glegroups.com, Al Viro <viro@...iv.linux.org.uk>
Subject: Re: KASAN: use-after-free Read in locks_delete_block

On Fri, 2018-11-16 at 12:37 -0800, Dmitry Vyukov wrote:
> On Thu, Nov 15, 2018 at 3:41 PM, NeilBrown <neilb@...e.com> wrote:
> > On Thu, Nov 15 2018, Dmitry Vyukov wrote:
> > 
> > > On Wed, Nov 14, 2018 at 2:36 AM, Jeff Layton <jlayton@...nel.org> wrote:
> > > > On Wed, 2018-11-14 at 07:40 +1100, NeilBrown wrote:
> > > > > On Tue, Nov 13 2018, Jeff Layton wrote:
> > > > > 
> > > > > > On Mon, 2018-11-12 at 12:34 -0800, syzbot wrote:
> > > > > > > Hello,
> > > > > > > 
> > > > > > > syzbot found the following crash on:
> > > > > > > 
> > > > > > > HEAD commit:    442b8cea2477 Add linux-next specific files for 20181109
> > > > > > > git tree:       linux-next
> > > > > > > console output: https://syzkaller.appspot.com/x/log.txt?x=115dbad5400000
> > > > > > > kernel config:  https://syzkaller.appspot.com/x/.config?x=2f72bdb11df9fbe8
> > > > > > > dashboard link: https://syzkaller.appspot.com/bug?extid=a4a3d526b4157113ec6a
> > > > > > > compiler:       gcc (GCC) 8.0.1 20180413 (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+a4a3d526b4157113ec6a@...kaller.appspotmail.com
> > > 
> > > /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
> > > 
> > > Hi Neil,
> > > 
> > > Please include the Reported-by tag next time.
> > 
> > I did, as you can see below.
> > 
> > When the fix is merged into the patch that introduced the bug, do you
> > still want the Reported-by there, even though the bug and the fix are no
> > longer visible?  What if I were to completely rewrite the patch - do I
> > still need the Reported-by??
> > 
> > I'm certainly happy to give credit where due, but keeping a complete
> > history of past bugs in a single commit seems excessive.
> > Please help me to understand your needs.
> 
> Here is the commit as I see it in linux-next:
> https://gist.githubusercontent.com/dvyukov/ac1791c98d95618a48548cef8df84558/raw/a3f819cca2f0bb47db0c2e88d35d020accb069b5/gistfile1.txt
> As far as I see it already includes the fix to locks_mandatory_area,
> but does not include the tag. Maybe it was merged somehow incorrectly.
>
> This is not so much about credit, but more about proper bug tracking.
> But reports on mailing lists are periodically being lost, and then it
> also may be hard to understand when a new crash is a new bug which
> needs to be reported again or an old lost bug.
> syzbot keeps track of all reported bugs and has a notion of
> open/active reports that still need human attention:
> https://syzkaller.appspot.com/#upstream
> and fixed/closed reports that don't need human attention anymore.
> The Reported-by tags are intercepted by syzbot and allows it to
> understand when a bug is fixed and needs to be closed.
> Keeping track of this is important for 2 reasons:
> 1. Closed/fixed bugs go away from the dashboard, so people don't go
> over them again and again.
> 2. If a bug is closed, syzbot will report new similarly looking bugs
> in future (otherwise it will just merge new crashes into the old bug,
> because it thinks it's still the old bug happenning).
> 
> linux-next is somewhat special because commits are being amended, so a
> commit can effectively fix itself. But one way or another syzbot needs
> to know about fixes. Reported-by tags take care of all tracking.
> Otherwise, a human needs to first notice that there is an already
> fixed bug that is still considered open, find the fixing commit and
> issue the "#syz fix" command as I did above. This is especially
> problematic for linux-next as it changes and bisection does not work.
> Here is more info on syzbot bug status tracking:
> https://goo.gl/tpsmEJ#bug-status-tracking
> 

Thanks for the explanation, Dmitry. I've added the tag to the patch in
my tree. It should show up in linux-next soon.

I still find it a little misleading to say that syzbot reported a bug
when it actually found a bug inside an earlier version of the patch, but
I'll just learn to get over it.

Thanks,
-- 
Jeff Layton <jlayton@...nel.org>