linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Greg KH <gregkh@linuxfoundation.org>
To: Will Deacon <will@kernel.org>
Cc: syzbot <syzbot+82defefbbd8527e1c2cb@syzkaller.appspotmail.com>,
	linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
	syzkaller-bugs@googlegroups.com, viro@zeniv.linux.org.uk,
	hdanton@sina.com, akpm@linux-foundation.org
Subject: Re: WARNING: refcount bug in cdev_get
Date: Wed, 4 Dec 2019 13:31:48 +0100	[thread overview]
Message-ID: <20191204123148.GA3626092@kroah.com> (raw)
In-Reply-To: <20191204115055.GA24783@willie-the-truck>

On Wed, Dec 04, 2019 at 11:50:56AM +0000, Will Deacon wrote:
> Hi all,
> 
> [+Hillf, +akpm, +Greg]
> 
> On Tue, Aug 20, 2019 at 03:58:06PM -0700, syzbot wrote:
> > syzbot found the following crash on:
> > 
> > HEAD commit:    2d63ba3e Merge tag 'pm-5.3-rc5' of git://git.kernel.org/pu..
> > git tree:       upstream
> > console output: https://syzkaller.appspot.com/x/log.txt?x=165d3302600000
> > kernel config:  https://syzkaller.appspot.com/x/.config?x=3ff364e429585cf2
> > dashboard link: https://syzkaller.appspot.com/bug?extid=82defefbbd8527e1c2cb
> > compiler:       gcc (GCC) 9.0.0 20181231 (experimental)
> > syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=16c8ab3c600000
> > C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=16be0c4c600000
> > 
> > Bisection is inconclusive: the bug happens on the oldest tested release.
> > 
> > bisection log:  https://syzkaller.appspot.com/x/bisect.txt?x=11de3622600000
> > console output: https://syzkaller.appspot.com/x/log.txt?x=15de3622600000
> > 
> > IMPORTANT: if you fix the bug, please add the following tag to the commit:
> > Reported-by: syzbot+82defefbbd8527e1c2cb@syzkaller.appspotmail.com
> > 
> > ------------[ cut here ]------------
> > refcount_t: increment on 0; use-after-free.
> > WARNING: CPU: 1 PID: 11828 at lib/refcount.c:156 refcount_inc_checked
> > lib/refcount.c:156 [inline]
> > WARNING: CPU: 1 PID: 11828 at lib/refcount.c:156
> > refcount_inc_checked+0x61/0x70 lib/refcount.c:154
> > Kernel panic - not syncing: panic_on_warn set ...
> 
> [...]
> 
> > RIP: 0010:refcount_inc_checked lib/refcount.c:156 [inline]
> > RIP: 0010:refcount_inc_checked+0x61/0x70 lib/refcount.c:154
> > Code: 1d 8e c6 64 06 31 ff 89 de e8 ab 9c 35 fe 84 db 75 dd e8 62 9b 35 fe
> > 48 c7 c7 00 05 c6 87 c6 05 6e c6 64 06 01 e8 67 26 07 fe <0f> 0b eb c1 90 90
> > 90 90 90 90 90 90 90 90 90 55 48 89 e5 41 57 41
> > RSP: 0018:ffff8880907d78b8 EFLAGS: 00010282
> > RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
> > RDX: 0000000000000000 RSI: ffffffff815c2466 RDI: ffffed10120faf09
> > RBP: ffff8880907d78c8 R08: ffff8880a771a200 R09: fffffbfff134ae48
> > R10: fffffbfff134ae47 R11: ffffffff89a5723f R12: ffff88809ea2bb80
> > R13: 0000000000000000 R14: ffff88809ff6cd40 R15: ffff8880a1c56480
> >  kref_get include/linux/kref.h:45 [inline]
> >  kobject_get+0x66/0xc0 lib/kobject.c:644
> >  cdev_get+0x60/0xb0 fs/char_dev.c:355
> >  chrdev_open+0xb0/0x6b0 fs/char_dev.c:400
> >  do_dentry_open+0x4df/0x1250 fs/open.c:797
> >  vfs_open+0xa0/0xd0 fs/open.c:906
> >  do_last fs/namei.c:3416 [inline]
> >  path_openat+0x10e9/0x4630 fs/namei.c:3533
> >  do_filp_open+0x1a1/0x280 fs/namei.c:3563
> >  do_sys_open+0x3fe/0x5d0 fs/open.c:1089
> 
> FWIW, we've run into this same crash on arm64 so it would be nice to see it
> fixed upstream. It looks like Hillf's reply (which included a patch) didn't
> make it to the kernel mailing lists for some reason, but it is available
> here:
> 
> https://groups.google.com/forum/#!original/syzkaller-bugs/PnQNxBrWv_8/X1ygj8d8DgAJ

No one is going to go and dig a patch out of google groups :(

> A simpler fix would just be to use kobject_get_unless_zero() directly in
> cdev_get(), but that looks odd in this specific case because chrdev_open()
> holds the 'cdev_lock' and you'd hope that finding the kobject in the inode
> with that held would mean that it's not being freed at the same time.

When using kref_get_unless_zero() that implies that a lock is not being
used and you are relying on the kobject only instead.

But I thought we had a lock in play here, so why would changing this
actually fix anything?

This code hasn't changed in 15+ years, what suddenly changed that causes
problems here?

thanks,

greg k-h

  reply	other threads:[~2019-12-04 12:31 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-20 22:58 WARNING: refcount bug in cdev_get syzbot
2019-12-04 11:50 ` Will Deacon
2019-12-04 12:31   ` Greg KH [this message]
2019-12-10 11:44     ` Will Deacon
2019-12-18 17:08       ` Will Deacon
2019-12-18 18:20         ` Greg KH
2019-12-19 11:59           ` Will Deacon
2019-12-24 12:59             ` Prateek Sood

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=20191204123148.GA3626092@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=akpm@linux-foundation.org \
    --cc=hdanton@sina.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=syzbot+82defefbbd8527e1c2cb@syzkaller.appspotmail.com \
    --cc=syzkaller-bugs@googlegroups.com \
    --cc=viro@zeniv.linux.org.uk \
    --cc=will@kernel.org \
    /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 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).