Re: [PATCH v4 04/27] rust: driver core: drop drvdata before devres release

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Critical] Reordering `post_unbind_rust` before `devres_release_all` violates LIFO resource management and introduces a critical Use-After-Free (UAF) vulnerability for drivers.
--

commit 13c328caac1fcbff52dab3f760a99e254b3f15b9
Author: Danilo Krummrich <dakr@kernel.org>

rust: driver core: drop drvdata before devres release

This commit moves the post_unbind_rust callback before devres_release_all()
in device_unbind_cleanup(). This allows Rust driver structs to hold direct
references to devres-managed resources by ensuring the driver's device
private data is dropped before devres actions are released.

> diff --git a/drivers/base/dd.c b/drivers/base/dd.c
> --- a/drivers/base/dd.c
> +++ b/drivers/base/dd.c
> @@ -593,9 +593,9 @@ static DEVICE_ATTR_RW(state_synced);
>  
>  static void device_unbind_cleanup(struct device *dev)
>  {
> -	devres_release_all(dev);
>  	if (dev->driver->p_cb.post_unbind_rust)
>  		dev->driver->p_cb.post_unbind_rust(dev);
> +	devres_release_all(dev);

[Severity: Critical]
Does this reordering introduce a use-after-free for devres cleanup actions
or active interrupts?

By executing post_unbind_rust() and freeing the driver data before
devres_release_all() is called, devm-managed resources are still active
while the driver data is gone. If a hardware interrupt or timer fires in
this window, or if a custom devm_add_action cleanup callback relies on a
context pointer to the driver data, won't it attempt to access freed memory?

To safely accommodate the lifetime requirements, should the driver data
instead be modeled as a devres resource itself so it is dropped at the
correct point in the unbind sequence?

>  	arch_teardown_dma_ops(dev);

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260521233501.1191842-1-dakr@kernel.org?part=4