From: Greg KH <gregkh@linuxfoundation.org>
To: Yufen Yu <yuyufen@huawei.com>
Cc: axboe@kernel.dk, linux-block@vger.kernel.org,
linux-fsdevel@vger.kernel.org, tj@kernel.org, jack@suse.cz,
bvanassche@acm.org, tytso@mit.edu
Subject: Re: [PATCH v2 0/7] bdi: fix use-after-free for bdi device
Date: Wed, 4 Mar 2020 18:29:07 +0100 [thread overview]
Message-ID: <20200304172907.GA1864710@kroah.com> (raw)
In-Reply-To: <20200226111851.55348-1-yuyufen@huawei.com>
On Wed, Feb 26, 2020 at 07:18:44PM +0800, Yufen Yu wrote:
> Hi, all
>
> We have reported a use-after-free crash for bdi device in
> __blkg_prfill_rwstat() (see Patch #3). The bug is caused by printing
> device kobj->name while the device and kobj->name has been freed by
> bdi_unregister().
How does that happen? Who has access to a kobject without also having
the reference count incremented at the same time? Is this through sysfs
or somewhere within the kernel itself?
> In fact, commit 68f23b8906 "memcg: fix a crash in wb_workfn when
> a device disappears" has tried to address the issue, but the code
> is till somewhat racy after that commit.
That commit is really odd, and I think is just papering over the real
issue, which is shown in the changelog for that commit.
A kobject can be unregistered, like bdi_unregister() does, even if there
are active references for it. But someone needs to also go around and
decrement those references in order for things to be properly freed.
It feels like the use of struct device (and by virtue of that, struct
kobject and really a kref) here is not being done correctly at all.
The rule should be, "whenever you pass a pointer to a device off, the
reference count is incremented". Somehow that is not happening here and
RCU is not going to solve the issue really, it's only going to delay the
problem from showing up until much later.
> In this patchset, we try to protect device lifetime with RCU, avoiding
> the device been freed when others used.
The struct device refcount should be all that is needed, don't use RCU
just to "delay freeing this object until some later time because someone
else might have a pointer to id". That's ripe for disaster.
> A way which maybe fix the problem is copy device name into special
> memory (as discussed in [0]), but that is also need lock protect.
Hah, all that is needed is the name here? That's sad.
thanks,
greg k-h
next prev parent reply other threads:[~2020-03-04 17:29 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-26 11:18 [PATCH v2 0/7] bdi: fix use-after-free for bdi device Yufen Yu
2020-02-26 11:18 ` [PATCH v2 1/7] blk-wbt: use bdi_dev_name() to get device name Yufen Yu
2020-02-26 11:18 ` [PATCH v2 2/7] fs/ceph: " Yufen Yu
2020-02-26 11:18 ` [PATCH v2 3/7] bdi: protect device lifetime with RCU Yufen Yu
2020-03-04 17:05 ` Tejun Heo
2020-03-04 17:22 ` Greg Kroah-Hartman
2020-03-04 17:23 ` Greg Kroah-Hartman
2020-03-04 18:50 ` Tejun Heo
2020-03-04 19:10 ` Theodore Y. Ts'o
2020-03-04 19:15 ` Tejun Heo
2020-03-04 20:05 ` Greg Kroah-Hartman
2020-03-05 1:22 ` Tejun Heo
2020-03-06 16:25 ` Greg Kroah-Hartman
2020-03-07 9:13 ` Yufen Yu
2020-02-26 11:18 ` [PATCH v2 4/7] bdi: create a new function bdi_get_dev_name() Yufen Yu
2020-02-26 11:18 ` [PATCH v2 5/7] bfq: fix potential kernel crash when print dev err info Yufen Yu
2020-02-26 11:18 ` [PATCH v2 6/7] memcg: fix crash in wb_workfn when bdi unregister Yufen Yu
2020-02-26 11:18 ` [PATCH v2 7/7] blk-wbt: replace bdi_dev_name() with bdi_get_dev_name() Yufen Yu
2020-03-04 17:29 ` Greg KH [this message]
2020-03-04 18:57 ` [PATCH v2 0/7] bdi: fix use-after-free for bdi device Tejun Heo
2020-03-04 20:07 ` Greg KH
2020-03-04 19:02 ` Theodore Y. Ts'o
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=20200304172907.GA1864710@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=axboe@kernel.dk \
--cc=bvanassche@acm.org \
--cc=jack@suse.cz \
--cc=linux-block@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=tj@kernel.org \
--cc=tytso@mit.edu \
--cc=yuyufen@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 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).