[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2025091224-blaming-untapped-6883@gregkh>
Date: Fri, 12 Sep 2025 10:30:45 +0200
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: Tzung-Bi Shih <tzungbi@...nel.org>
Cc: Benson Leung <bleung@...omium.org>,
"Rafael J . Wysocki" <rafael@...nel.org>,
Danilo Krummrich <dakr@...nel.org>,
Jonathan Corbet <corbet@....net>, Shuah Khan <shuah@...nel.org>,
Dawid Niedzwiecki <dawidn@...gle.com>, linux-doc@...r.kernel.org,
linux-kernel@...r.kernel.org, chrome-platform@...ts.linux.dev,
linux-kselftest@...r.kernel.org,
Laurent Pinchart <laurent.pinchart@...asonboard.com>,
Bartosz Golaszewski <bartosz.golaszewski@...aro.org>,
Wolfram Sang <wsa+renesas@...g-engineering.com>
Subject: Re: [PATCH v3 0/5] platform/chrome: Fix a possible UAF via revocable
On Fri, Sep 12, 2025 at 08:17:12AM +0000, Tzung-Bi Shih wrote:
> This is a follow-up series of [1]. It tries to fix a possible UAF in the
> fops of cros_ec_chardev after the underlying protocol device has gone by
> using revocable.
>
> The 1st patch introduces the revocable which is an implementation of ideas
> from the talk [2].
>
> The 2nd and 3rd patches add test cases for revocable in Kunit and selftest.
>
> The 4th patch converts existing protocol devices to resource providers
> of cros_ec_device.
>
> The 5th patch converts cros_ec_chardev to a resource consumer of
> cros_ec_device to fix the UAF.
>
> [1] https://lore.kernel.org/chrome-platform/20250721044456.2736300-6-tzungbi@kernel.org/
> [2] https://lpc.events/event/17/contributions/1627/
>
> Cc: Laurent Pinchart <laurent.pinchart@...asonboard.com>
> Cc: Bartosz Golaszewski <bartosz.golaszewski@...aro.org>
> Cc: Wolfram Sang <wsa+renesas@...g-engineering.com>
This is, frankly, wonderful work. Thanks so much for doing this, it's
what many of us have been wanting to see for a very long time but none
of us got around to actually doing it.
And it has tests! And documentation! Couldn't ask for more.
We can bikeshed about the REVOCABLE() macro name, but frankly, you wrote
it, you get to pick it :)
Laurent, Bartosz, Wolfram, any objection to this series? I think this
addresses the issues that all of you have been raising for years with
our access of pointers that have different lifecycles from other
structures (i.e. struct cdev from struct device).
Also, Danilo, if you get the chance, can you give this a review as well?
At first glance it looks good to me, but as you wrote the Rust
implementation of this feature, a second pair of eyes would be great to
have if you have the time.
thanks,
greg k-h
Powered by blists - more mailing lists