linux-kernel - Re: [PATCH v3 0/5] platform/chrome: Fix a possible UAF via revocable

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <1dc06657-e136-45c2-8012-9199194bfc9b@kernel.org>
Date: Fri, 12 Sep 2025 18:22:48 +0200
From: Danilo Krummrich <dakr@...nel.org>
To: Laurent Pinchart <laurent.pinchart@...asonboard.com>
Cc: Bartosz Golaszewski <brgl@...ev.pl>,
 Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
 Tzung-Bi Shih <tzungbi@...nel.org>,
 Bartosz Golaszewski <bartosz.golaszewski@...aro.org>,
 Krzysztof Kozlowski <krzk@...nel.org>, Benson Leung <bleung@...omium.org>,
 "Rafael J . Wysocki" <rafael@...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,
 Wolfram Sang <wsa+renesas@...g-engineering.com>,
 Dan Williams <dan.j.williams@...el.com>
Subject: Re: [PATCH v3 0/5] platform/chrome: Fix a possible UAF via revocable

On 9/12/25 4:54 PM, Laurent Pinchart wrote:
> On Fri, Sep 12, 2025 at 04:44:56PM +0200, Bartosz Golaszewski wrote:
>> On Fri, Sep 12, 2025 at 4:40 PM Greg Kroah-Hartman
>> <gregkh@...uxfoundation.org> wrote:
>>> Either way, I think this patch series stands on its own, it doesn't
>>> require cdev to implement it, drivers can use it to wrap a cdev if they
>>> want to.  We have other structures that want to do this type of thing
>>> today as is proof with the rust implementation for the devm api.
>>
>> Yeah, I'm not against this going upstream. If more development is
>> needed for this to be usable in other parts of the kernel, that can be
>> done gradually. Literally no subsystem ever was perfect on day 1.
> 
> To be clear, I'm not against the API being merged for the use cases that
> would benefit from it, but I don't want to see drivers using it to
> protect from the cdev/unregistration race.

I mean, revocable is really a synchronization primitive in the end that
"revokes" access to some resource in a race free way.

So, technically, it probably belongs into lib/.

I think the reason it ended up in drivers/base/ is that one common use case is
to revoke a device resource from a driver when the device is unbound from this
driver; or in other words devres is an obvious user.

So, I think that any other API (cdev, devres, etc.) should  be built on top of it.

This is also what we do in Rust, Revocable is just a common synchronization
primitive and the (only) user it has is currently Devres building on top of it.