CVE-2026-93106 in Linux
Summary
by MITRE • 09/18/2026
In the Linux kernel, the following vulnerability has been resolved:
crash_dump: release keyring reference at the correct time
restore_dm_crypt_keys_to_thread_keyring() gets a reference to the user keyring before restoring the saved dm-crypt keys.
The same keyring reference is then passed to add_key_to_keyring() for each saved key, but add_key_to_keyring() drops that reference on every call. This is only balanced when exactly one key is restored. With multiple keys, the keyring reference is dropped too many times and may trigger a refcount underflow or use-after-free.
When more than five keys are restored, a refcount underflow/use-after-free warning can be triggered.
The early error paths after lookup_user_key() also return without dropping the keyring reference.
Keep ownership of the keyring reference in restore_dm_crypt_keys_to_thread_keyring(), drop it once on all exit paths, and make add_key_to_keyring() only use the reference without consuming it.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 09/18/2026
The Linux kernel vulnerability identified involves a critical refcount management error within the dm-crypt subsystem during crash dump operations. Specifically, the function restore_dm_crypt_keys_to_thread_keyring acquires a reference to the user keyring before attempting to restore saved encryption keys. This design choice is intended to ensure that the target keyring remains valid throughout the restoration process. However, the implementation incorrectly passes this acquired reference directly into add_key_to_keyring for each individual key being restored. The function add_key_to_keyring consumes and drops the provided reference upon successful execution. Consequently, when multiple keys are present in the saved state, the reference count is decremented once per key rather than just once at the end of the operation. This logic flaw results in a premature release of the keyring resource if more than one key is restored, leading to severe memory safety violations such as refcount underflow or use-after-free conditions when the system attempts to access freed memory structures associated with that keyring.
The operational impact of this vulnerability is significant for systems relying on dm-crypt encryption and crash dump functionality. When an error occurs during the restoration process, particularly in early exit paths following lookup_user_key, the code returns without releasing the acquired keyring reference. While this specific path causes a memory leak rather than immediate corruption, it contributes to resource exhaustion over time or under repeated stress conditions. More critically, when multiple keys are successfully processed, the double-dropping of references triggers kernel warnings related to refcount underflow and use-after-free scenarios. These errors can lead to system instability, potential denial of service through kernel panic, or in worst-case scenarios, privilege escalation if an attacker can manipulate the state such that freed memory is reallocated for malicious purposes. The threshold mentioned indicates that issues manifest when more than five keys are restored, highlighting a scalability issue within the key management logic rather than a simple single-key edge case.
From a vulnerability classification perspective, this flaw aligns with CWE-362 Concurrent Execution using Shared Resource with Improper Synchronization, specifically regarding reference counting errors in multi-threaded or sequential execution contexts where resource ownership is mismanaged. It also relates to CWE-415 Double Free and CWE-787 Out-of-bounds Write if the underflow leads to memory corruption that affects adjacent structures. In terms of attack vectors, this falls under ATT&CK technique T1059 Command and Scripting Interpreter or more accurately T1203 Exploitation for Client Execution if leveraged via local privilege escalation through crafted crash dump scenarios. The vulnerability stems from improper handling of object lifecycles in the kernel space, where reference counting semantics were not consistently applied across function boundaries.
The resolution involves correcting the ownership model of the keyring reference within restore_dm_crypt_keys_to_thread_keyring. Instead of passing the reference to add_key_to_keyring and allowing it to be consumed multiple times, the code now retains ownership in the restoring function. The modified logic ensures that add_key_to_keyring uses the reference without consuming or dropping it during each iteration. Furthermore, explicit cleanup paths have been added to ensure the keyring reference is dropped exactly once upon all exit conditions, including error states following lookup_user_key. This approach guarantees that the refcount remains balanced regardless of the number of keys restored or whether an error occurs mid-process. By decoupling the usage of the reference from its lifecycle management, the vulnerability eliminates both the underflow risk and the memory leak associated with early returns.
Mitigation strategies for organizations running affected Linux kernels involve applying vendor-provided patches that update the dm-crypt subsystem to reflect these changes in keyring handling logic. Administrators should monitor kernel logs for refcount warnings or use-after-free traces, which may indicate exploitation attempts or latent instability before a patch is applied. In environments where crash dumps are frequently generated with complex encryption configurations involving multiple keys, prioritizing this update is essential to maintain system integrity and prevent potential privilege escalation vectors arising from memory corruption bugs in the kernel core subsystems responsible for cryptographic key management.