From: Tejun Heo <tj@kernel.org>
To: Christian Brauner <brauner@kernel.org>
Cc: Suren Baghdasaryan <surenb@google.com>,
Greg KH <gregkh@linuxfoundation.org>,
peterz@infradead.org, lujialin4@huawei.com,
lizefan.x@bytedance.com, hannes@cmpxchg.org, mingo@redhat.com,
ebiggers@kernel.org, oleg@redhat.com, akpm@linux-foundation.org,
viro@zeniv.linux.org.uk, juri.lelli@redhat.com,
vincent.guittot@linaro.org, dietmar.eggemann@arm.com,
rostedt@goodmis.org, bsegall@google.com, mgorman@suse.de,
bristot@redhat.com, vschneid@redhat.com,
linux-kernel@vger.kernel.org, cgroups@vger.kernel.org,
linux-fsdevel@vger.kernel.org, kernel-team@android.com
Subject: Re: [PATCH 1/2] kernfs: add kernfs_ops.free operation to free resources tied to the file
Date: Mon, 10 Jul 2023 10:38:46 -1000 [thread overview]
Message-ID: <ZKxsVuDqdr6IJeyv@slm.duckdns.org> (raw)
In-Reply-To: <20230630-fegefeuer-urheber-0a25a219520d@brauner>
Hello,
On Fri, Jun 30, 2023 at 10:21:17AM +0200, Christian Brauner wrote:
> What I'm mostly reacting to is that there's a kernfs_ops->release()
> method which mirrors f_op->release() but can be called when there are
> still users which is counterintuitive for release semantics. And that
> ultimately caused this UAF issue which was rather subtle given how long
> it took to track down the root cause.
>
> A rmdir() isn't triggering a f_op->release() if there are still file
> references but it's apparently triggering a kernfs_ops->release(). It
> feels like this should at least be documented in struct kernfs_ops...
Oh yeah, better documentation would be great. The core part here is that
kernfs is the layer which is implementing the revoke-like semantics
specifically to allow kernfs users (the ones that implement kernfs_ops) can
synchronously abort their involvement at will. So, from those users' POV,
->release is being called when it should be. The problem here was that PSI
was mixing objects from two layers with different lifetime rules, which
obviously causes issues.
As Suren's new fix shows, the fix is just using the matching object whose
lifetime is governed by kernfs. While this shows up in a subtle way for
poll, for all other operations, this is almost completely transprent.
Thanks.
--
tejun
next prev parent reply other threads:[~2023-07-10 20:38 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-26 20:17 Suren Baghdasaryan
2023-06-26 20:17 ` [PATCH 2/2] sched/psi: tie psi trigger destruction with file's lifecycle Suren Baghdasaryan
2023-06-26 20:21 ` [PATCH 1/2] kernfs: add kernfs_ops.free operation to free resources tied to the file Suren Baghdasaryan
2023-06-26 20:31 ` Tejun Heo
2023-06-26 20:39 ` Suren Baghdasaryan
2023-06-27 8:24 ` Christian Brauner
2023-06-27 17:09 ` Suren Baghdasaryan
2023-06-27 17:30 ` Christian Brauner
2023-06-27 17:36 ` Suren Baghdasaryan
2023-06-27 18:42 ` Tejun Heo
2023-06-27 20:09 ` Suren Baghdasaryan
2023-06-27 21:43 ` Suren Baghdasaryan
2023-06-27 21:58 ` Suren Baghdasaryan
2023-06-28 1:54 ` Tejun Heo
2023-06-28 3:09 ` Suren Baghdasaryan
2023-06-28 7:26 ` Christian Brauner
2023-06-28 7:46 ` Suren Baghdasaryan
2023-06-28 8:41 ` Christian Brauner
2023-06-28 16:28 ` Suren Baghdasaryan
2023-06-28 17:35 ` Christian Brauner
2023-06-28 18:02 ` Tejun Heo
2023-06-28 18:18 ` Suren Baghdasaryan
2023-06-28 18:42 ` Greg KH
2023-06-28 20:12 ` Suren Baghdasaryan
2023-06-28 20:34 ` Tejun Heo
2023-06-28 21:50 ` Suren Baghdasaryan
2023-06-30 0:59 ` Suren Baghdasaryan
2023-06-30 8:21 ` Christian Brauner
2023-07-10 20:38 ` Tejun Heo [this message]
2023-06-28 17:58 ` Tejun Heo
2023-06-27 6:25 ` Greg KH
2023-06-27 17:03 ` Suren Baghdasaryan
2023-06-27 17:23 ` Christian Brauner
2023-06-27 17:36 ` Matthew Wilcox
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=ZKxsVuDqdr6IJeyv@slm.duckdns.org \
--to=tj@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=brauner@kernel.org \
--cc=bristot@redhat.com \
--cc=bsegall@google.com \
--cc=cgroups@vger.kernel.org \
--cc=dietmar.eggemann@arm.com \
--cc=ebiggers@kernel.org \
--cc=gregkh@linuxfoundation.org \
--cc=hannes@cmpxchg.org \
--cc=juri.lelli@redhat.com \
--cc=kernel-team@android.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lizefan.x@bytedance.com \
--cc=lujialin4@huawei.com \
--cc=mgorman@suse.de \
--cc=mingo@redhat.com \
--cc=oleg@redhat.com \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=surenb@google.com \
--cc=vincent.guittot@linaro.org \
--cc=viro@zeniv.linux.org.uk \
--cc=vschneid@redhat.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
all inboxes | Powered by JetHome®