CVE-2026-89997 in Linux
Summary
by MITRE • 09/16/2026
In the Linux kernel, the following vulnerability has been resolved:
dm: fix resume-vs-remove race
If the user issues the resume ioctl and the remove ioctl at the same time, it may be possible that the device is resumed after it is suspended in __dm_destroy. The result is that the table is destroyed without calling the postsuspend method.
Dm targets expect that they may be removed only after the postsuspend method method was called. If we break this expectation, it can cause misbehavior in various targets. For example - in the dm-integrity target, the reboot notifier is not unregistered, leading to use-after-free.
Fix this bug by refusing to resume if the device is being destroyed.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/16/2026
The Linux kernel's Device Mapper subsystem manages logical volumes and storage devices through a complex layer of abstraction that allows for flexible configuration of block devices. A critical race condition has been identified within this subsystem, specifically involving the interaction between the resume and remove operations on a device-mapper target. This vulnerability arises when an application or system process issues both the ioctl to resume a suspended device and the ioctl to remove it concurrently. The core issue lies in the timing of state transitions during the destruction phase of a device mapper device. When __dm_destroy is invoked, it suspends the device as part of its cleanup routine. However, if a concurrent resume operation occurs after this suspension but before the full teardown sequence completes, the kernel may proceed to resume the device while it is technically in the process of being destroyed.
This race condition violates the fundamental lifecycle expectations of device mapper targets. These targets are designed under the assumption that they will only be removed or unloaded after their postsuspend method has been successfully executed. The postsuspend routine is critical for performing necessary cleanup tasks, such as unregistering kernel notifiers and freeing allocated resources associated with the target's state. When the resume operation interrupts this sequence by bringing a device back to an active state while it should remain suspended for destruction, the subsequent table destruction occurs without invoking these essential cleanup functions. This deviation from the expected operational flow creates a window where internal data structures are invalidated or freed prematurely relative to their usage status within the kernel subsystems that depend on them.
The impact of this vulnerability is particularly severe in targets like dm-integrity, which rely heavily on proper lifecycle management for security and stability reasons. In the case of dm-integrity, failing to call the postsuspend method means that reboot notifiers registered by the target are never unregistered. Consequently, when a system event triggers these notifiers after the underlying memory structures have been freed due to the premature table destruction, it results in a use-after-free condition. This type of memory corruption can lead to kernel panics, data integrity violations, or potentially allow for arbitrary code execution if an attacker can control the contents of the freed memory and trigger its reuse through specific system interactions. The vulnerability effectively undermines the reliability guarantees provided by the device mapper architecture, exposing systems to instability and potential exploitation vectors derived from standard administrative operations.
To mitigate this risk, the kernel developers have implemented a fix that enforces stricter state checks during the resume operation. Specifically, the code now refuses to resume a device if it is currently in the process of being destroyed. This change ensures that the destruction sequence remains atomic with respect to suspension and removal states, preventing any concurrent operations from interfering with the cleanup phase. By blocking resumes on devices marked for destruction, the kernel guarantees that postsuspend methods are always called before resources are released, thereby preserving memory safety and system stability. System administrators should ensure their kernels are updated to include this patch, as it addresses a fundamental concurrency flaw in how device mapper states are managed under concurrent access scenarios. This fix aligns with best practices for handling race conditions in kernel subsystems by enforcing strict state machine transitions that prevent invalid operations during critical cleanup windows.