From: Luis Chamberlain <mcgrof@kernel.org>
To: "yukuai (C)" <yukuai3@huawei.com>
Cc: Ming Lei <ming.lei@redhat.com>,
axboe@kernel.dk, viro@zeniv.linux.org.uk,
gregkh@linuxfoundation.org, rostedt@goodmis.org,
mingo@redhat.com, jack@suse.cz, nstange@suse.de, mhocko@suse.com,
linux-block@vger.kernel.org, linux-fsdevel@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [RFC 0/3] block: address blktrace use-after-free
Date: Tue, 7 Apr 2020 19:00:04 +0000 [thread overview]
Message-ID: <20200407190004.GG11244@42.do-not-panic.com> (raw)
In-Reply-To: <0e753195-72fb-ce83-16a1-176f2c3cea6a@huawei.com>
On Tue, Apr 07, 2020 at 10:47:01AM +0800, yukuai (C) wrote:
> On 2020/4/3 16:19, Ming Lei wrote:
>
> > BTW, Yu Kuai posted one patch for this issue, looks that approach
> > is simpler:
> >
> > https://lore.kernel.org/linux-block/20200324132315.22133-1-yukuai3@huawei.com/
> >
> >
>
> I think the issue might not be fixed with the patch seires.
>
> At first, I think there are two key points for the issure:
> 1. The final release of queue is delayed in a workqueue
> 2. The creation of 'q->debugfs_dir' might failed(only if 1 exist)
> And if we can fix any of the above problem, the UAF issue will be fixed.
> (BTW, I did not come up with a good idea for problem 1, and my approach
> is for problem 2.)
>
> The third patch "block: avoid deferral of blk_release_queue() work" is
> not enough to fix problem 1:
> a. if CONFIG_DEBUG_KOBJECT_RELEASE is enable:
> static void kobject_release(struct kref *kref)
> {
> struct kobject *kobj = container_of(kref, struct kobject, kref);
> #ifdef CONFIG_DEBUG_KOBJECT_RELEASE
> unsigned long delay = HZ + HZ * (get_random_int() & 0x3);
> pr_info("kobject: '%s' (%p): %s, parent %p (delayed %ld)\n",
> ┊kobject_name(kobj), kobj, __func__, kobj->parent, delay);
> INIT_DELAYED_WORK(&kobj->release, kobject_delayed_cleanup);
>
> schedule_delayed_work(&kobj->release, delay);
> #else
> kobject_cleanup(kobj);
> #endif
> }
> b. when 'kobject_put' is called from blk_cleanup_queue, can we make sure
> it is the last reference?
You are right, I think I know the fix for this now. Will run some more
tests.
Luis
next prev parent reply other threads:[~2020-04-07 19:00 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-01 23:59 [RFC 0/3] block: address blktrace use-after-free Luis Chamberlain
2020-04-02 0:00 ` [RFC 1/3] block: move main block debugfs initialization to its own file Luis Chamberlain
2020-04-05 3:12 ` Bart Van Assche
2020-04-06 14:23 ` Luis Chamberlain
2020-04-02 0:00 ` [RFC 2/3] blktrace: fix debugfs use after free Luis Chamberlain
2020-04-02 1:57 ` Eric Sandeen
2020-04-02 16:14 ` Luis Chamberlain
2020-04-03 14:19 ` kbuild test robot
2020-04-05 3:39 ` Bart Van Assche
2020-04-06 1:27 ` Eric Sandeen
2020-04-06 4:25 ` Bart Van Assche
2020-04-06 9:18 ` Nicolai Stange
2020-04-06 15:19 ` Luis Chamberlain
2020-04-07 8:15 ` Luis Chamberlain
2020-04-06 14:29 ` Eric Sandeen
2020-04-07 8:09 ` Luis Chamberlain
2020-04-06 15:14 ` Luis Chamberlain
2020-04-02 0:00 ` [RFC 3/3] block: avoid deferral of blk_release_queue() work Luis Chamberlain
2020-04-02 3:39 ` Bart Van Assche
2020-04-02 14:49 ` Nicolai Stange
2020-04-06 9:11 ` Nicolai Stange
2020-04-09 18:11 ` Luis Chamberlain
2020-04-02 7:44 ` [RFC 0/3] block: address blktrace use-after-free Greg KH
2020-04-03 8:19 ` Ming Lei
2020-04-03 14:06 ` Luis Chamberlain
2020-04-03 14:13 ` Bart Van Assche
2020-04-03 19:49 ` Luis Chamberlain
2020-04-07 2:47 ` yukuai (C)
2020-04-07 19:00 ` Luis Chamberlain [this message]
2020-04-09 20:59 ` Luis Chamberlain
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=20200407190004.GG11244@42.do-not-panic.com \
--to=mcgrof@kernel.org \
--cc=axboe@kernel.dk \
--cc=gregkh@linuxfoundation.org \
--cc=jack@suse.cz \
--cc=linux-block@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mhocko@suse.com \
--cc=ming.lei@redhat.com \
--cc=mingo@redhat.com \
--cc=nstange@suse.de \
--cc=rostedt@goodmis.org \
--cc=viro@zeniv.linux.org.uk \
--cc=yukuai3@huawei.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.