linux-kernel - Re: [PATCH v7 0/3] drivers/base: Introduce 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: <DFQ5D44A0348.PZJIGPL972N@kernel.org>
Date: Fri, 16 Jan 2026 17:16:58 +0100
From: "Danilo Krummrich" <dakr@...nel.org>
To: "Laurent Pinchart" <laurent.pinchart@...asonboard.com>
Cc: "Greg Kroah-Hartman" <gregkh@...uxfoundation.org>, "Tzung-Bi Shih"
 <tzungbi@...nel.org>, "Benson Leung" <bleung@...omium.org>, "Rafael J .
 Wysocki" <rafael@...nel.org>, "Bartosz Golaszewski" <brgl@...ev.pl>, "Linus
 Walleij" <linusw@...nel.org>, "Jonathan Corbet" <corbet@....net>, "Shuah
 Khan" <shuah@...nel.org>, <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>, "Simona Vetter"
 <simona.vetter@...ll.ch>, "Dan Williams" <dan.j.williams@...el.com>, "Jason
 Gunthorpe" <jgg@...dia.com>, <linux-gpio@...r.kernel.org>
Subject: Re: [PATCH v7 0/3] drivers/base: Introduce revocable

On Fri Jan 16, 2026 at 5:04 PM CET, Laurent Pinchart wrote:
> The revocable mechanism isn't the right solution for races between device
> removal and userspace access.

I think you have to differenciate, as it depends on the resource:

If the resource is a device resource (e.g. MMIO resource regions) that must not
be held by the driver after its bound device has been unbound, you have to
revoke the resource from the driver, i.e. you can't just fix it with a reference
count.

Effectively, that's what devres does, it releases the resource when the device
is unbound. Revocable takes care of avoiding a UAF of a subsequent access.

We subsystems that invented subsystem specific implementations for a revocable
mechanism for exactly those cases.

For instance, there is drm_dev_enter() drm_dev_exit() and drm_dev_unplug() which
ultimately does the same things as DRM specific implementation.

If the resource is not a device resource, then revocable is clearly not the
correct solution however.