From: Luis Chamberlain <mcgrof@kernel.org>
To: Bart Van Assche <bvanassche@acm.org>
Cc: axboe@kernel.dk, viro@zeniv.linux.org.uk,
gregkh@linuxfoundation.org, rostedt@goodmis.org,
mingo@redhat.com, jack@suse.cz, ming.lei@redhat.com,
nstange@suse.de, mhocko@suse.com, linux-block@vger.kernel.org,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
Omar Sandoval <osandov@fb.com>, Hannes Reinecke <hare@suse.com>,
Michal Hocko <mhocko@kernel.org>,
syzbot+603294af2d01acfdd6da@syzkaller.appspotmail.com
Subject: Re: [RFC 2/3] blktrace: fix debugfs use after free
Date: Mon, 6 Apr 2020 15:14:22 +0000 [thread overview]
Message-ID: <20200406151422.GC11244@42.do-not-panic.com> (raw)
In-Reply-To: <3640b16b-abda-5160-301a-6a0ee67365b4@acm.org>
On Sat, Apr 04, 2020 at 08:39:47PM -0700, Bart Van Assche wrote:
> On 2020-04-01 17:00, Luis Chamberlain wrote:
> > korg#205713 then was used to create CVE-2019-19770 and claims that
> > the bug is in a use-after-free in the debugfs core code. The
> > implications of this being a generic UAF on debugfs would be
> > much more severe, as it would imply parent dentries can sometimes
> > not be possitive, which is something claim is not possible.
> ^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> positive? is there perhaps a word missing here?
Sorry yeah, this was supposed to say:
it would imply parent dentries can sometimes not be positive, which
is just not possible.
> > It turns out that the issue actually is a mis-use of debugfs for
> > the multiqueue case, and the fragile nature of how we free the
> > directory used to keep track of blktrace debugfs files. Omar's
> > commit assumed the parent directory would be kept with
> > debugfs_lookup() but this is not the case, only the dentry is
> > kept around. We also special-case a solution for multiqueue
> > given that for multiqueue code we always instantiate the debugfs
> > directory for the request queue. We were leaving it only to chance,
> > if someone happens to use blktrace, on single queue block devices
> > for the respective debugfs directory be created.
>
> Since the legacy block layer is gone, the above explanation may have to
> be rephrased.
Will do.
> > We can fix the UAF by simply using a debugfs directory which is
> > always created for singlequeue and multiqueue block devices. This
> > simplifies the code considerably, with the only penalty now being
> > that we're always creating the request queue directory debugfs
> > directory for the block device on singlequeue block devices.
>
> Same comment here - the legacy block layer is gone. I think that today
> all block drivers are either request-based and multiqueue or so-called
> make_request drivers. See also the output of git grep -nHw
> blk_alloc_queue for examples of the latter category.
Will adjust.
> > This patch then also contends the severity of CVE-2019-19770 as
> > this issue is only possible using root to shoot yourself in the
> > foot by also misuing blktrace.
> ^^^^^^^
> misusing?
>
> > diff --git a/block/blk-mq-debugfs.c b/block/blk-mq-debugfs.c
> > index b3f2ba483992..bda9378eab90 100644
> > --- a/block/blk-mq-debugfs.c
> > +++ b/block/blk-mq-debugfs.c
> > @@ -823,9 +823,6 @@ void blk_mq_debugfs_register(struct request_queue *q)
> > struct blk_mq_hw_ctx *hctx;
> > int i;
> >
> > - q->debugfs_dir = debugfs_create_dir(kobject_name(q->kobj.parent),
> > - blk_debugfs_root);
> > -
> > debugfs_create_files(q->debugfs_dir, q, blk_mq_debugfs_queue_attrs);
> >
> > /*
>
> [ ... ]
>
> > static void blk_mq_debugfs_register_ctx(struct blk_mq_hw_ctx *hctx,
> > diff --git a/block/blk-sysfs.c b/block/blk-sysfs.c
> > index fca9b158f4a0..20f20b0fa0b9 100644
> > --- a/block/blk-sysfs.c
> > +++ b/block/blk-sysfs.c
> > @@ -895,6 +895,7 @@ static void __blk_release_queue(struct work_struct *work)
> >
> > blk_trace_shutdown(q);
> >
> > + blk_q_debugfs_unregister(q);
> > if (queue_is_mq(q))
> > blk_mq_debugfs_unregister(q);
>
> Does this patch change the behavior of the block layer from only
> registering a debugfs directory for request-based block devices to
> registering a debugfs directory for request-based and make_request based
> block devices? Is that behavior change an intended behavior change?
Yes, specifically this was already done, however for request-based block
devices this was done upon init, and for make_request based devices this
was only instantiated *iff* blktrace was used at least once. It is
actually a bit difficult to see the later, given the rq->debugfs_dir was
not used per se for make_request based block devices, but instead
the debugfs_create_dir(buts->name, blk_debugfs_root) call was made
directly, which happens to end up being the same directory as
debugfs_create_dir(kobject_name(q->kobj.parent), blk_debugfs_root)
called on block/blk-mq-debugfs.c.
This changes the block layer so that the rq->debugfs_dir is always created
now if debugfs is enabled.
Note that blktrace already depends on debugfs. What was missing in this
patch too was this hunk:
--- a/include/linux/blkdev.h
+++ b/include/linux/blkdev.h
@@ -569,8 +569,10 @@ struct request_queue {
struct list_head tag_set_list;
struct bio_set bio_split;
-#ifdef CONFIG_BLK_DEBUG_FS
+#ifdef CONFIG_DEBUG_FS
struct dentry *debugfs_dir;
+#endif
+#ifdef CONFIG_BLK_DEBUG_FS
struct dentry
*sched_debugfs_dir;
struct dentry
*rqos_debugfs_dir;
#endif
next prev parent reply other threads:[~2020-04-06 15:14 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 [this message]
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
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=20200406151422.GC11244@42.do-not-panic.com \
--to=mcgrof@kernel.org \
--cc=axboe@kernel.dk \
--cc=bvanassche@acm.org \
--cc=gregkh@linuxfoundation.org \
--cc=hare@suse.com \
--cc=jack@suse.cz \
--cc=linux-block@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mhocko@kernel.org \
--cc=mhocko@suse.com \
--cc=ming.lei@redhat.com \
--cc=mingo@redhat.com \
--cc=nstange@suse.de \
--cc=osandov@fb.com \
--cc=rostedt@goodmis.org \
--cc=syzbot+603294af2d01acfdd6da@syzkaller.appspotmail.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.