All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@lst.de>
To: Christian Brauner <brauner@kernel.org>
Cc: Christoph Hellwig <hch@lst.de>,
	syzbot <syzbot+2faac0423fdc9692822b@syzkaller.appspotmail.com>,
	jack@suse.cz, linux-fsdevel@vger.kernel.org,
	linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com,
	viro@zeniv.linux.org.uk
Subject: Re: [syzbot] [fs?] KASAN: slab-use-after-free Read in test_bdev_super_fc
Date: Fri, 4 Aug 2023 16:02:01 +0200	[thread overview]
Message-ID: <20230804140201.GA27600@lst.de> (raw)
In-Reply-To: <20230804-abstieg-behilflich-eda2ce9c2c0f@brauner>

On Fri, Aug 04, 2023 at 03:20:45PM +0200, Christian Brauner wrote:
> On Fri, Aug 04, 2023 at 12:14:08PM +0200, Christoph Hellwig wrote:
> > FYI, I can reproduce this trivially locally, but even after spending a
> > significant time with the trace I'm still puzzled at what is going
> > on.  I've started trying to make sense of the lockdep report about
> > returning to userspace with s_umount held, originall locked in
> > get_tree_bdev and am still missing how it could happen.
> 
> So in the old scheme:
> 
> s = alloc_super()
> -> down_write_nested(&s->s_umount, SINGLE_DEPTH_NESTING);
> 
> and assume you're not finding an old one immediately afterwards you'd
> 
> -> spin_lock(&sb_lock)
> 
> static int set_bdev_super(struct super_block *s, void *data)
> {
>         s->s_bdev = data;
>         s->s_dev = s->s_bdev->bd_dev;
>         s->s_bdi = bdi_get(s->s_bdev->bd_disk->bdi);
> 
>         if (bdev_stable_writes(s->s_bdev))
>                 s->s_iflags |= SB_I_STABLE_WRITES;
>         return 0;
> }
> 
> -> spin_unlock(&sb_lock)
> 
> in the new scheme you're doing:
> 
> s = alloc_super()
> -> down_write_nested(&s->s_umount, SINGLE_DEPTH_NESTING);
> 
> and assume you're not finding an old one immediately afterwards you'd
> 
> up_write(&s->s_umount);
> 
> error = setup_bdev_super(s, fc->sb_flags, fc);
> -> spin_lock(&sb_lock);
>    sb->s_bdev = bdev;
>    sb->s_bdi = bdi_get(bdev->bd_disk->bdi);
>    if (bdev_stable_writes(bdev))
>            sb->s_iflags |= SB_I_STABLE_WRITES;
> -> spin_unlock(&sb_lock);
> 
> down_write(&s->s_umount);
> 
> Which looks like the lock ordering here is changed?

Yes, that none only should be safe, but more importantly should not
lead to a return to userspace with s_umount held.

Anyway, debugging a regression in mainline right now so I'm taking a
break from this one.

  reply	other threads:[~2023-08-04 14:02 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-03 22:14 [syzbot] [fs?] KASAN: slab-use-after-free Read in test_bdev_super_fc syzbot
2023-08-04 10:14 ` Christoph Hellwig
2023-08-04 13:20   ` Christian Brauner
2023-08-04 14:02     ` Christoph Hellwig [this message]
2023-08-04 14:36       ` Christian Brauner
2023-08-04 14:43         ` Christoph Hellwig
2023-08-04 14:49           ` Christian Brauner
2023-08-04 15:29             ` Christian Brauner
2023-08-05  8:57               ` Christoph Hellwig
     [not found]             ` <20230805084316.1699-1-hdanton@sina.com>
2023-08-05  8:48               ` Christoph Hellwig
     [not found] <20230804125406.1583-1-hdanton@sina.com>
2023-08-04 19:13 ` syzbot
     [not found] <20230804233428.1642-1-hdanton@sina.com>
2023-08-05  0:11 ` syzbot

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=20230804140201.GA27600@lst.de \
    --to=hch@lst.de \
    --cc=brauner@kernel.org \
    --cc=jack@suse.cz \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=syzbot+2faac0423fdc9692822b@syzkaller.appspotmail.com \
    --cc=syzkaller-bugs@googlegroups.com \
    --cc=viro@zeniv.linux.org.uk \
    /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.