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] [thread-next>] [day] [month] [year] [list]

Message-Id: <DCZG9N3QIRNP.1HUDPVL61FZVR@kernel.org>
Date: Mon, 22 Sep 2025 17:55:43 +0200
From: "Danilo Krummrich" <dakr@...nel.org>
To: "Jason Gunthorpe" <jgg@...dia.com>
Cc: "Laurent Pinchart" <laurent.pinchart@...asonboard.com>, "Greg
 Kroah-Hartman" <gregkh@...uxfoundation.org>, "Bartosz Golaszewski"
 <brgl@...ev.pl>, "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 Mon Sep 22, 2025 at 5:10 PM CEST, Jason Gunthorpe wrote:
> As was said later in this thread, it would be a real shame to see
> people implement revocable in drivers instead of rely on subsystems to
> have sane unregistration semantics where the subsystem guarentees that
> no driver callbacks are running after unregister. You never need
> driver revocable in a world like that.

I fully agree with that, in C there is indeed no value of a revocable type when
subsystems can guarantee "sane unregistration semantics".

I say "in C" because in C there is no way to get a proof by the compiler that
we're in a scope (e.g. through the subsystem guarentee) where the device is
guaranteed to be bound (which we can in Rust).

So, effectively, we're not getting any value out of the revocable in C in such a
case: In the best case, we're just bypassing the revocable by accessing the
pointer unchecked (regardless whether that's valid or not); in the worst case
we're introducing a useless SRCU read side critical section.

(In Rust the compiler will stop us from accessing the pointer unchecked if we're
not in a scope where unchecked access is valid.)

So, I think in C revocable should be restricted to use-cases where scopes are
unbound by design. DRM device callbacks are an example for that and it's the
reason why things like drm_dev_{enter,exit}() and drm_dev_unplug() exist. In the
end, those are exactly the same as revocable implemented in a slightly different
way.

- Danilo