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

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

[Tzung-Bi Shih]

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 just discovered the Kernel Summit topic suggestion is a two-step process,
and I only completed the first step (the website submission), missing the
second.

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

[Jiri Kosina]

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.

Thanks,

-- 
Jiri Kosina
SUSE Labs

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

[Greg KH]

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.

thanks,

greg k-h

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

[Tzung-Bi Shih]

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.

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

[Linus Walleij]

On Sat, Sep 13, 2025 at 4:49 PM Tzung-Bi Shih <tzungbi@kernel.org> wrote:

> 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.

I looked at it and it looks very interesting.

We have faced this problem in the GPIO subsystem because a lot
of GPIO expanders are on pluggable buses such as USB, while
there may still be consumers not only in kernelspace but also
in userspace.

We remove the underlying device driver and irqchip etc in
gpiochip_remove() with:

        /* Numb the device, cancelling all outstanding operations */
        rcu_assign_pointer(gdev->chip, NULL);

but any userspace consumers are
"dangling", which in practice means that e.g.
linehandle_ioctl() gets called and then:

        if (!rcu_access_pointer(lh->gdev->chip))
                return -ENODEV;

This seems to be using a similar idea or the same idea and using
RCU as well because you have:

void *revocable_try_access(struct revocable *rev) __acquires(&rev->rp->srcu)
{
    struct revocable_provider *rp = rev->rp;

    rev->idx = srcu_read_lock(&rp->srcu);
    return rcu_dereference(rp->res);
}

AFAICT this is pretty much the same, but more bells and whistles and
more elegantly designed as a slot-in solution :)

So we would probably be able to move over to this API very easily.

Yours,
Linus Walleij