CVE-2026-89764: rust: devres: fix race between concurrent revokers
In the Linux kernel, the following vulnerability has been resolved:
rust: devres: fix race between concurrent revokers
There is a potential race condition when two paths try to revoke a Devres concurrently.
The driver core's devresreleaseall() calls Revocable::revoke() via the release callback, while Devres::drop() calls revokenosync() on another CPU.
The revoker that does not claim the isavailable swap returns immediately, but the revoker that did may still be executing dropinplace() on the inner data. This can cause a use-after-free when the other revoker's caller proceeds to drop adjacent resources that dropinplace() still references (e.g., Devres<DmaMappedSgt> racing with SGTable freeing the backing sgtable and pages).
Fix this by adding a Completion. The release callback signals the Completion after revoke() finishes, and Devres::drop() waits for it when it loses the isavailable swap. This ensures the wrapped object is fully torn down before Devres::drop() returns.
Affected Software
Event History
Frequently Asked Questions
What conditions are required for this race to occur?
Two concurrent revocation paths must act on the same Rust Devres object: the driver core release path calling Revocable::revoke() and Devres::drop() on another CPU calling revoke_nosync(). The race becomes dangerous when teardown of adjacent resources can free data still referenced by the wrapped object's drop_in_place() operation.
Which systems or components are realistically exposed?
The issue applies to Linux kernel Rust devres usage where a Devres object can be released concurrently through driver-core cleanup and its Drop implementation. The provided information does not identify specific drivers, kernel versions, or configurations.
What is the practical impact if the race is triggered?
It can cause a use-after-free during resource teardown. One revoker may return and permit adjacent resources to be dropped while the other is still executing drop_in_place() on data that references those resources.
Is there a mitigation described for systems that cannot immediately apply the fix?
No operational workaround is provided. The described resolution makes Devres::drop() wait for completion of the release callback's revoke() operation when it did not claim the availability state.