← Back to CVE intelligence
CVE intelligence

CVE-2026-89764

Vulnerability intelligence

Published Sep 11, 2026Sources checked Nov 10, 2026
7.8HIGHCVSS out of 10
What this means

Review the available evidence

CVE-2026-89764 and is rated High severity with a CVSS score of 7.8. It is not in the current CISA KEV record we collected. That does not prove exploitation has not occurred.

What to do next

Remediation and response

Ubuntu Security Notices guidance

Vendor revision: Nov 10, 2026
Vendor remediation details

This update corrects flaws in the following subsystems: - Network file systems library; - Stream parser; - ARM64 architecture; - PowerPC architecture; - RISC-V architecture; - S390 architecture; - User-Mode Linux (UML); - x86 architecture; - Block layer subsystem; - Android drivers; - Bluetooth drivers; - TPM device driver; - DPLL subsystem; - EDAC drivers; - GPIO subsystem; - GPU drivers; - HID subsystem; - IIO subsystem; - IIO ADC drivers; - InfiniBand drivers; - Input Device (Miscellaneous) drivers; - Multiple devices driver; - MemoryStick subsystem; - MMC subsystem; - MTD block device drivers; - Network drivers; - Ethernet bonding driver; - Mellanox network drivers; - STMicroelectronics network drivers; - Ethernet team driver; - MediaTek network drivers; - NVME drivers; - Device tree a

CISA KEVNot listedBased on the latest collected catalog
EPSS0.2%Estimated 30-day exploitation probability
Ransomware useNot markedCISA KEV ransomware field
Threat actors0Source-linked actor relationships
Overview

What is CVE-2026-89764?

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.

Source: NVD