Cloudanix VulnDB

CVE-2026-89764

High · 7.8

CVSS

7.8

EPSS

0.2%

Published

Sep 11, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A timing problem in how the Linux kernel cleans up certain resources could let a local user crash the machine or gain elevated access.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
Low
Impact
Full Compromise
Component
OS kernel
Class
Race Condition
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

Race condition in Linux kernel rust devres allows concurrent revocation paths (devres_release_all via release callback and Devres::drop via revoke_nosync) to both proceed past the is_available swap, enabling one path to execute drop_in_place on the inner object while the other continues to drop adjacent resources that reference the same memory (use-after-free).

Why it matters to the business

Local attackers on affected Linux systems can trigger crashes, kernel panics, or arbitrary code execution, leading to denial of service, data corruption, or full host compromise; widespread exposure in any kernel using the Rust devres abstractions increases operational risk until patched kernels are deployed.

How an attack unfolds

An attacker with local access crafts concurrent operations that trigger Devres revocation from multiple CPUs simultaneously; one revocation wins the is_available swap and begins teardown while the losing path immediately proceeds to free dependent structures, resulting in use-after-free when the first path still holds references.

How to fix it

Update to a Linux kernel release containing the Completion synchronization fix in rust/devres; rebuild and deploy the patched kernel across all affected systems; verify the patch is present by inspecting the devres.rs source for the added wait on the Completion after losing the is_available swap.

How to confirm the fix worked

Confirm kernel source contains the Completion signaling after revoke() and the corresponding wait in Devres::drop(); run concurrency stress tests exercising Revocable::revoke and Devres drop paths in parallel; monitor for absence of use-after-free reports under load.

Typical attack path

  1. Obtain local code execution on target Linux host
  2. Trigger concurrent revocation of the same Devres object from separate CPUs or threads
  3. Win/lose the is_available atomic swap in a way that leaves drop_in_place running while dependent resources are freed
  4. Leverage resulting use-after-free for memory corruption or privilege escalation

How to detect it

Search kernel logs and crash dumps for use-after-free signatures involving devres, DmaMappedSgt, or sg_table structures; look for concurrent revocation patterns in ftrace or perf traces around Revocable and Devres drop paths; no public exploit artifacts are known.

What your security team should do

  • Prioritize kernel updates on all systems exposing the Rust devres code path
  • Apply patches within standard maintenance windows given low EPSS and no known in-the-wild exploitation
  • Add kernel build verification steps to ensure the race fix is included
  • Monitor upstream stable branches for backports of the Completion change

The record

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 devres_release_all() calls Revocable::revoke() via the release callback, while Devres::drop() calls revoke_nosync() on another CPU. The revoker that does not claim the is_available swap returns immediately, but the revoker that did may still be executing drop_in_place() on the inner data. This can cause a use-after-free when the other revoker's caller proceeds to drop adjacent resources that drop_in_place() still references (e.g., Devres<DmaMappedSgt> racing with SGTable freeing the backing sg_table 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 is_available swap. This ensures the wrapped object is fully torn down before Devres::drop() returns.

Affected packages

Ecosystem Package Introduced Fixed