All of lore.kernel.org
 help / color / mirror / Atom feed
From: Al Viro <viro@ZenIV.linux.org.uk>
To: Eric Biggers <ebiggers3@gmail.com>
Cc: syzbot <syzbot+f3bd89a5ab3266b10540@syzkaller.appspotmail.com>,
	linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
	syzkaller-bugs@googlegroups.com, linux-nfs@vger.kernel.org
Subject: Re: BUG: corrupted list in __dentry_kill
Date: Mon, 2 Apr 2018 21:37:46 +0100	[thread overview]
Message-ID: <20180402203745.GE30522@ZenIV.linux.org.uk> (raw)
In-Reply-To: <20180402064437.GB30522@ZenIV.linux.org.uk>

On Mon, Apr 02, 2018 at 07:44:37AM +0100, Al Viro wrote:
> On Sun, Apr 01, 2018 at 02:48:54PM -0700, Eric Biggers wrote:
> > [+Cc linux-nfs]
> > > 
> > > [   42.965515] net/sunrpc/rpc_pipe.c: __rpc_create_common failed to allocate inode for dentry blocklayout
> > > [   42.967234] net/sunrpc/rpc_pipe.c: rpc_mkpipe_dentry() failed to create pipe nfs/blocklayout (errno = -12)
> 
> 	AFAICS, there's nothing to zero nn->bl_device_pipe->dentry after
> nfs4blocklayout_unregister_sb(), is there?  If nothing else, what's
> going to happen after mount/umount/mount with failing
> nfs4blocklayout_register_sb()?  AFAICS, we'll have stale pointer to
> dentry sitting in nn->bl_device_pipe->dentry, and call rpc_unlink()
> on it while cleaning up after the failing mount.
> 
> 	I don't think that's all there is to it, but it does smell like
> a bug.

That's not all.  Making nfs4blocklayout_register_sb() immediately fail
(without doing anything) leads to that oops on the very first attempt
to mount rpc_pipefs.

Matter of fact, rpc_gssd_dummy_depopulate() is garbage.  I don't know
how it had been tested, but it will do an extra dput() of gssd_dentry
whenever it's called.  _Any_ failure that sends us to err_depopulate:
(== any failure in rpc_pipefs_notifier_list callbacks) means an oops
there on attempt to dput() an already freed dentry.

Hell, turn that if (err) goto err_depopulate; into
if (err || !strcmp(current->comm, "bugger")) goto err_depopulate;
cp /bin/mount /root/bugger, then boot with init=/bin/sh
and
cd /root; ./bugger -t rpc_pipefs none /mnt
will trigger just that.

WARNING: multiple messages have this Message-ID (diff)
From: Al Viro <viro@ZenIV.linux.org.uk>
To: Eric Biggers <ebiggers3@gmail.com>
Cc: syzbot <syzbot+f3bd89a5ab3266b10540@syzkaller.appspotmail.com>,
	linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
	syzkaller-bugs@googlegroups.com, linux-nfs@vger.kernel.org
Subject: Re: BUG: corrupted list in __dentry_kill
Date: Mon, 2 Apr 2018 21:37:46 +0100	[thread overview]
Message-ID: <20180402203745.GE30522@ZenIV.linux.org.uk> (raw)
In-Reply-To: <20180402064437.GB30522@ZenIV.linux.org.uk>

On Mon, Apr 02, 2018 at 07:44:37AM +0100, Al Viro wrote:
> On Sun, Apr 01, 2018 at 02:48:54PM -0700, Eric Biggers wrote:
> > [+Cc linux-nfs]
> > > 
> > > [   42.965515] net/sunrpc/rpc_pipe.c: __rpc_create_common failed to allocate inode for dentry blocklayout
> > > [   42.967234] net/sunrpc/rpc_pipe.c: rpc_mkpipe_dentry() failed to create pipe nfs/blocklayout (errno = -12)
> 
> 	AFAICS, there's nothing to zero nn->bl_device_pipe->dentry after
> nfs4blocklayout_unregister_sb(), is there?  If nothing else, what's
> going to happen after mount/umount/mount with failing
> nfs4blocklayout_register_sb()?  AFAICS, we'll have stale pointer to
> dentry sitting in nn->bl_device_pipe->dentry, and call rpc_unlink()
> on it while cleaning up after the failing mount.
> 
> 	I don't think that's all there is to it, but it does smell like
> a bug.

That's not all.  Making nfs4blocklayout_register_sb() immediately fail
(without doing anything) leads to that oops on the very first attempt
to mount rpc_pipefs.

Matter of fact, rpc_gssd_dummy_depopulate() is garbage.  I don't know
how it had been tested, but it will do an extra dput() of gssd_dentry
whenever it's called.  _Any_ failure that sends us to err_depopulate:
(== any failure in rpc_pipefs_notifier_list callbacks) means an oops
there on attempt to dput() an already freed dentry.

Hell, turn that if (err) goto�err_depopulate; into
if (err || !strcmp(current->comm, "bugger")) goto err_depopulate;
cp /bin/mount /root/bugger, then boot with init=/bin/sh
and
cd /root; ./bugger -t rpc_pipefs none /mnt
will trigger just that.

  reply	other threads:[~2018-04-02 20:37 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-31 23:01 BUG: corrupted list in __dentry_kill syzbot
2018-04-01  3:35 ` Al Viro
2018-04-01 20:05   ` Al Viro
2018-04-01 21:05     ` Eric Biggers
2018-04-01 21:48       ` Eric Biggers
2018-04-01 22:20         ` Matthew Wilcox
2018-04-02  6:44         ` Al Viro
2018-04-02 20:37           ` Al Viro [this message]
2018-04-02 20:37             ` Al Viro
2018-04-20  2:20 ` Eric Biggers

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180402203745.GE30522@ZenIV.linux.org.uk \
    --to=viro@zeniv.linux.org.uk \
    --cc=ebiggers3@gmail.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-nfs@vger.kernel.org \
    --cc=syzbot+f3bd89a5ab3266b10540@syzkaller.appspotmail.com \
    --cc=syzkaller-bugs@googlegroups.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.