linux-kernel - Re: kernel BUG at fs/inode.c:LINE!

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: <5c581e6eadc946b965e3138c9daffda75b1fba56.camel@themaw.net>
Date:   Wed, 10 Apr 2019 19:57:44 +0800
From:   Ian Kent <raven@...maw.net>
To:     Dmitry Vyukov <dvyukov@...gle.com>
Cc:     Al Viro <viro@...iv.linux.org.uk>,
        syzbot <syzbot+5399ed0832693e29f392@...kaller.appspotmail.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Amir Goldstein <amir73il@...il.com>,
        linux-fsdevel <linux-fsdevel@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>,
        syzkaller-bugs <syzkaller-bugs@...glegroups.com>
Subject: Re: kernel BUG at fs/inode.c:LINE!

On Wed, 2019-04-10 at 13:40 +0200, Dmitry Vyukov wrote:
> On Wed, Apr 10, 2019 at 12:35 PM Ian Kent <raven@...maw.net> wrote:
> > 
> > On Wed, 2019-04-10 at 10:27 +0200, Dmitry Vyukov wrote:
> > > On Wed, Apr 10, 2019 at 2:26 AM Al Viro <viro@...iv.linux.org.uk> wrote:
> > > > 
> > > > On Tue, Apr 09, 2019 at 07:36:00AM -0700, syzbot wrote:
> > > > > Bisection is inconclusive: the first bad commit could be any of:
> > > > 
> > > > [snip the useless pile]
> > > > 
> > > > > bisection log:
> > > > > https://syzkaller.appspot.com/x/bisect.txt?x=15e1fc2b200000
> > > > > start commit:   [unknown
> > > > > git tree:       linux-next
> > > > > dashboard link:
> > > > > https://syzkaller.appspot.com/bug?extid=5399ed0832693e29f392
> > > > > syz repro:      
> > > > > https://syzkaller.appspot.com/x/repro.syz?x=101032b3400000
> > > > > C reproducer:   
> > > > > https://syzkaller.appspot.com/x/repro.c?x=16534063400000
> > > > > 
> > > > > For information about bisection process see:
> > > > > https://goo.gl/tpsmEJ#bisection
> > > > 
> > > > If I'm not misreading the "crash report" there, it has injected an
> > > > allocation
> > > > failure in dentry allocation in d_make_root() from autofs_fill_super() (
> > > >         root_inode = autofs_get_inode(s, S_IFDIR | 0755);
> > > >         root = d_make_root(root_inode);
> > > > ) which has triggered iput() on the inode passed to d_make_root() (as it
> > > > ought
> > > > to).  At which point it stepped into some BUG_ON() in fs/inode.c, but
> > > > I've
> > > > no idea which one it is - line numbers do not match anything in linux-
> > > > next
> > > > or in mainline.  Reported line 1566 is
> > > >                 if (inode->i_nlink && (inode->i_state & I_DIRTY_TIME)) {
> > > > in all of them; as the matter of fact, the diff in fs/inode.c between
> > > > -next and mainline is empty.
> > > > 
> > > > There is a BUG_ON() several lines prior, and in 4.20 it used to be line
> > > > 1566,
> > > > so _probably_ that's what it is.  With that assumption, it's
> > > >         BUG_ON(inode->i_state & I_CLEAR);
> > > > IOW, we'd got I_CLEAR in the inode passed to d_make_root() there.  Which
> > > > should not happen - the inode must have come from new_inode(), which
> > > > gets it from new_inode_pseudo(), which zeroes ->i_state.  And I_CLEAR
> > > > is set only in clear_inode().  For autofs inodes that can come only
> > > > from autofs_evict_inode(), called as ->evict() from evict_inode().
> > > > Which should never ever be called for inode with positive ->i_count...
> > > > 
> > > > It might be memory corruption; it might be a dangling inode pointer
> > > > somewhere, it might be something else.
> > > > 
> > > > To get any further we really need a confirmation of the identity of
> > > > triggered BUG_ON().
> > > > 
> > > > As an aside, your "sample crash reports" would've been much more useful
> > > > if
> > > > they went with commit SHA1 in question, especially when they contain
> > > > line
> > > > numbers.
> > > 
> > > Hi Al,
> > > 
> > > This is the commit for matching lines:
> > > 
> > > > HEAD commit:    d14b746c6c1c Add linux-next specific files for 20181214
> > 
> > Are you sure?
> > what does 20181214 mean?
> 
> Yes, I just copy-pasted from the report. "d14b746c6c1c" is the commit
> hash. "Add linux-next specific files for 20181214" is the commit
> subject.
> 
> 
> > Looking at current next code (and several branches) it doesn't
> > appear the problem is possible?
> > 
> > > > git tree:       linux-next
> > 
> > But which branch is it really, master (which doesn't match the
> > line numbers btw)?
> 
> This is d14b746c6c1c commit hash. I don't know if there is a branch
> with HEAD pointing to this commit or not, but it seems unimportant.
> Tree+commit is the identity of code state.
> 
> 
> > > fs/inode.c:1566 points to:
> > > 
> > > void iput(struct inode *inode)
> > > {
> > >     ...
> > >     BUG_ON(inode->i_state & I_CLEAR);
> > > 
> > > 
> > > The dashboard page provides kernel git repository and commit for each
> > > crash.
> > 
> > Those links don't seem to make sense to me ...
> > 
> > Help me out here!
> 
> There is git repo name provided and commit hash. It's meant to be
> self-explanatory. What exactly is unclear?

I'm unable to find a branch matching the line numbers.

Given that, on the face of it, the scenario is impossible I'm
seeking clarification on what linux-next to look at for the
sake of accuracy.

So I'm wondering if this testing done using the master branch
or one of the daily branches one would use to check for conflicts
before posting?

Or perhaps the master branch has been updated and the testing was
done on something different.

Ian