From: Tzung-Bi Shih <tzungbi@kernel.org>
To: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Wolfram Sang <wsa+renesas@sang-engineering.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Jason Gunthorpe <jgg@nvidia.com>,
Benson Leung <bleung@chromium.org>,
"Rafael J . Wysocki" <rafael@kernel.org>,
Danilo Krummrich <dakr@kernel.org>,
Jonathan Corbet <corbet@lwn.net>, Shuah Khan <shuah@kernel.org>,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
chrome-platform@lists.linux.dev, linux-kselftest@vger.kernel.org,
Bartosz Golaszewski <brgl@bgdev.pl>,
Simona Vetter <simona.vetter@ffwll.ch>,
Dan Williams <dan.j.williams@intel.com>
Subject: Re: [PATCH v5 5/7] revocable: Add fops replacement
Date: Fri, 12 Dec 2025 08:32:46 +0000 [thread overview]
Message-ID: <aTvTLpFmyVxanvYC@google.com> (raw)
In-Reply-To: <aTrZMJ8R6zybFNHR@google.com>
On Thu, Dec 11, 2025 at 02:46:08PM +0000, Tzung-Bi Shih wrote:
> On Thu, Dec 11, 2025 at 10:43:06PM +0900, Laurent Pinchart wrote:
> > On Thu, Dec 11, 2025 at 05:36:57PM +0900, Wolfram Sang wrote:
> > >
> > > > > Isn't there even prototype code from Dan Williams?
> > > > >
> > > > > "[PATCH 1/3] cdev: Finish the cdev api with queued mode support"
> > > > >
> > > > > https://lkml.org/lkml/2021/1/20/997
> > > >
> > > > I mentioned that in my LPC talk in 2022 :-) I think we should merge that
> > > > (or a rebased, possibly improved version of it). I've meant to try
> > > > plumbing that series in V4L2 but couldn't find the time so far.
> > >
> > > Yes, you mentioned it in 2022 but maybe not everyone in this thread is
> > > right now aware of it ;) The patch above got changes requested. I talked
> > > to Dan very briefly about it at Maintainers Summit 2023 and he was also
> > > open (back then) to pick it up again.
> >
> > After discussing with Tzung-Bi today after his presentation (thank you
> > Tzung-Bi for your time, it helped me understand the problem you're
> > facing better), I wonder if this series is fixing the issue in the right
> > place.
>
> Thank you for your time too for providing me some more context.
>
> > At the core of the problem is a devm_kzalloc() call to allocate
> > driver-specific data. That data structure is then referenced from a
> > cdev, which can dereference is after it gets freed. It seems that
> > reference-counting the data structure instead of using devm_kzalloc()
> > could be a better solution.
>
> After discussing with you, I recalled this was one of my previous attempts.
> See the series [1] and Greg's feedback [2].
>
> I want to provide some more context about the cdev level solution. I failed
> to do so for misc device [3] mainly because all misc devices share a same
> cdev [4]. If one of the misc device drivers "revoke" the cdev, all other
> drivers stop working.
>
> I'm not saying we shouldn't seek for cdev level solution. But at least it
> doesn't work for misc device. Still need some other ways for misc devices.
>
> [1] https://lore.kernel.org/chrome-platform/20250721044456.2736300-8-tzungbi@kernel.org/
> [2] https://lore.kernel.org/chrome-platform/2025072114-unifier-screen-1594@gregkh/
> [3] https://lore.kernel.org/chrome-platform/aQ1xfHuyg1y8eJQ_@google.com/
> [4] https://elixir.bootlin.com/linux/v6.17/source/drivers/char/misc.c#L299
Continuing the context, the subsystem level solution for misc device without
revocable could be more or less like the following patch. Observed 2 main
issues of it:
1. Because it tries to synchronize the misc device and open files, it has a
big lock between them. misc_deregister() needs to wait for all open files.
I think this is a common issue shared by "replacing file operations"
approaches. All file operations are considered as critical sections.
2. It doesn't stop existing open files. UAF still happens when the dangling
FD tries to access the miscdevice (which should have been freed).
diff --git a/drivers/char/misc.c b/drivers/char/misc.c
index 726516fb0a3b..0ce415da10c2 100644
--- a/drivers/char/misc.c
+++ b/drivers/char/misc.c
@@ -115,6 +116,89 @@ static const struct seq_operations misc_seq_ops = {
};
#endif
+static struct miscdevice *find_miscdevice(int minor)
+{
+ struct miscdevice *c;
+
+ list_for_each_entry(c, &misc_list, list)
+ if (c->minor == minor)
+ return c;
+ return NULL;
+}
+
+static __poll_t misc_some_poll(struct file *filp, poll_table *wait)
+{
+ struct miscdevice *c;
+
+ c = find_miscdevice(iminor(filp->f_inode));
+ if (!c)
+ return -ENODEV;
+ if (!c->fops->poll)
+ return 0;
+
+ guard(mutex)(&c->some_lock);
+ if (!c->registered)
+ return -ENODEV;
+ return c->fops->poll(filp, wait);
+}
+
+static const struct file_operations misc_some_fops = {
+ .poll = misc_some_poll,
+ .read = misc_some_read,
+ .unlocked_ioctl = misc_some_ioctl,
+ .release = misc_some_release,
+};
@@ -161,6 +245,7 @@ static int misc_open(struct inode *inode, struct file *file)
replace_fops(file, new_fops);
if (file->f_op->open)
err = file->f_op->open(inode, file);
+ file->f_op = &misc_some_fops;
fail:
mutex_unlock(&misc_mtx);
return err;
@@ -262,6 +347,8 @@ int misc_register(struct miscdevice *misc)
goto out;
}
+ mutex_init(&misc->some_lock);
+ misc->registered = true;
/*
* Add it to the front, so that later devices can "override"
* earlier defaults
@@ -283,6 +370,9 @@ EXPORT_SYMBOL(misc_register);
void misc_deregister(struct miscdevice *misc)
{
+ scoped_guard(mutex, &misc->some_lock)
+ misc->registered = false;
+
mutex_lock(&misc_mtx);
list_del_init(&misc->list);
device_destroy(&misc_class, MKDEV(MISC_MAJOR, misc->minor));
diff --git a/include/linux/miscdevice.h b/include/linux/miscdevice.h
index 7d0aa718499c..3b42cf273f97 100644
--- a/include/linux/miscdevice.h
+++ b/include/linux/miscdevice.h
@@ -92,6 +92,8 @@ struct miscdevice {
const struct attribute_group **groups;
const char *nodename;
umode_t mode;
+ struct mutex some_lock;
+ bool registered;
};
next prev parent reply other threads:[~2025-12-12 8:32 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-16 5:41 [PATCH v5 0/7] platform/chrome: Fix a possible UAF via revocable Tzung-Bi Shih
2025-10-16 5:41 ` [PATCH v5 1/7] revocable: Revocable resource management Tzung-Bi Shih
2025-10-16 5:41 ` [PATCH v5 2/7] revocable: Add Kunit test cases Tzung-Bi Shih
2025-10-16 5:42 ` [PATCH v5 3/7] selftests: revocable: Add kselftest cases Tzung-Bi Shih
2025-10-16 5:42 ` [PATCH v5 4/7] platform/chrome: Protect cros_ec_device lifecycle with revocable Tzung-Bi Shih
2025-10-16 5:42 ` [PATCH v5 5/7] revocable: Add fops replacement Tzung-Bi Shih
2025-10-16 12:31 ` Jason Gunthorpe
2025-10-17 2:36 ` Tzung-Bi Shih
2025-10-17 13:49 ` Jason Gunthorpe
2025-10-17 16:07 ` Tzung-Bi Shih
2025-10-17 16:21 ` Jason Gunthorpe
2025-10-19 15:08 ` Tzung-Bi Shih
2025-10-20 11:57 ` Jason Gunthorpe
2025-10-21 4:49 ` Tzung-Bi Shih
2025-10-21 12:15 ` Jason Gunthorpe
2025-10-23 14:22 ` Tzung-Bi Shih
2025-10-23 14:51 ` Jason Gunthorpe
2025-10-23 15:04 ` Greg Kroah-Hartman
2025-10-23 15:57 ` Jason Gunthorpe
2025-10-23 16:20 ` Danilo Krummrich
2025-10-23 16:48 ` Jason Gunthorpe
2025-10-23 18:30 ` Danilo Krummrich
2025-12-11 3:23 ` Laurent Pinchart
2025-12-11 3:47 ` Wolfram Sang
2025-12-11 8:05 ` Laurent Pinchart
2025-12-11 8:36 ` Wolfram Sang
2025-12-11 13:43 ` Laurent Pinchart
2025-12-11 14:46 ` Tzung-Bi Shih
2025-12-12 8:32 ` Tzung-Bi Shih [this message]
2025-11-07 4:11 ` Tzung-Bi Shih
2025-11-07 14:12 ` Jason Gunthorpe
2025-10-17 16:29 ` Danilo Krummrich
2025-10-17 16:37 ` Jason Gunthorpe
2025-10-17 18:19 ` Danilo Krummrich
2025-10-17 18:44 ` Jason Gunthorpe
2025-10-17 21:41 ` Danilo Krummrich
2025-10-17 22:56 ` Jason Gunthorpe
2025-10-23 15:32 ` Danilo Krummrich
2025-10-16 18:38 ` Randy Dunlap
2025-10-17 2:41 ` Tzung-Bi Shih
2025-10-16 5:42 ` [PATCH v5 6/7] char: misc: Leverage revocable " Tzung-Bi Shih
2025-10-16 5:42 ` [PATCH v5 7/7] platform/chrome: cros_ec_chardev: Secure cros_ec_device via revocable Tzung-Bi Shih
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=aTvTLpFmyVxanvYC@google.com \
--to=tzungbi@kernel.org \
--cc=bleung@chromium.org \
--cc=brgl@bgdev.pl \
--cc=chrome-platform@lists.linux.dev \
--cc=corbet@lwn.net \
--cc=dakr@kernel.org \
--cc=dan.j.williams@intel.com \
--cc=gregkh@linuxfoundation.org \
--cc=jgg@nvidia.com \
--cc=laurent.pinchart@ideasonboard.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=rafael@kernel.org \
--cc=shuah@kernel.org \
--cc=simona.vetter@ffwll.ch \
--cc=wsa+renesas@sang-engineering.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).