Re: [TECH TOPIC] Revocable: a mechanism for preventing "classic" use-after-free bugs

[Tzung-Bi Shih <tzungbi@kernel.org>]

On Sun, Sep 14, 2025 at 08:45:44AM +0200, Greg KH wrote:
> On Sun, Sep 14, 2025 at 12:19:47AM +0200, Jiri Kosina wrote:
> > On Sat, 13 Sep 2025, Tzung-Bi Shih wrote:
> > 
> > > Abstract
> > > 
> > > A "classic" Use-After-Free (UAF) can occur when resources tied to
> > > hot-pluggable devices are accessed after the device has been removed.  For
> > > example, an open file descriptor may hold references to such resources; if
> > > the device is unplugged, subsequent file operations on that descriptor can
> > > trigger an UAF.  This talk, a follow-up to a previous presentation[1],
> > > explores an approach to this challenge.
> > > 
> > > We will present "revocable"[2], a new kernel mechanism for resource
> > > management.  A revocable allows a resource provider (e.g., a device driver)
> > > to invalidate access to a resource from a consumer (e.g., a character device)
> > > when the underlying device is no longer available.  Once a resource is
> > > revoked, any further attempts to use it will fail gracefully, thus preventing
> > > the UAF.
> > > 
> > > We will discuss the design and implementation of the revocable mechanism and
> > > its application in the ChromeOS Embedded Controller drivers to fix a
> > > real-world UAF bug.  We hope to also start a discussion on how this generic
> > > mechanism could be adopted by other drivers to handle similar resource
> > > lifecycle issues.
> > > 
> > > [1] https://lpc.events/event/17/contributions/1627/
> > > [2] https://lore.kernel.org/chrome-platform/20250820081645.847919-1-tzungbi@kernel.org/T/#u
> > 
> > I will be honest and admit that I haven't looked at the linked resources 
> > yet in a big enough detail, but judging purely from the abstract above, I 
> > believe this will immediately met by "how is this different from 
> > device-managed (devm_*) resources?", so hinting about that in abstract 
> > already might be helpful.
> 
> It's quite different, devm_ can be built on top of it, like it was done
> for the rust implementation for devm_*, so yes, it would be good to say
> something about that.

Thank you both for the feedback, that's a very good point.

Here is the revised (in the second paragraph) abstract:

A "classic" Use-After-Free (UAF) can occur when resources tied to
hot-pluggable devices are accessed after the device has been removed.  For
example, an open file descriptor may hold references to such resources; if
the device is unplugged, subsequent file operations on that descriptor can
trigger an UAF.  This talk, a follow-up to a previous presentation[1],
explores an approach to this challenge.

We will present "revocable"[2], a new kernel mechanism for resource
management.  While the existing devres framework manages resource lifetime
and cleanup, revocable addresses the distinct problem of access invalidation.
A revocable allows a resource provider (e.g., a device driver) to invalidate
access to a resource from a consumer (e.g., a character device) when the
underlying device is no longer available.  Once a resource is revoked, any
further attempts to use it will fail gracefully, thus preventing the UAF.

We will discuss the design and implementation of the revocable mechanism and
its application in the ChromeOS Embedded Controller drivers to fix a
real-world UAF bug.  We hope to also start a discussion on how this generic
mechanism could be adopted by other drivers to handle similar resource
lifecycle issues.