CVE-2022-49897 in Linux
Summary
by MITRE • 05/01/2025
In the Linux kernel, the following vulnerability has been resolved:
fscrypt: fix keyring memory leak on mount failure
Commit d7e7b9af104c ("fscrypt: stop using keyrings subsystem for fscrypt_master_key") moved the keyring destruction from __put_super() to generic_shutdown_super() so that the filesystem's block device(s) are still available. Unfortunately, this causes a memory leak in the case where a mount is attempted with the test_dummy_encryption mount option, but the mount fails after the option has already been processed.
To fix this, attempt the keyring destruction in both places.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 03/15/2026
The vulnerability described in CVE-2022-49897 represents a memory management issue within the Linux kernel's fscrypt subsystem that manifests as a memory leak during filesystem mount operations. This flaw specifically impacts the handling of encryption keys when the test_dummy_encryption mount option is utilized, creating a scenario where allocated memory resources are not properly released even when mount operations fail. The issue stems from a code change implemented in commit d7e7b9af104c that altered the timing and location of keyring destruction operations, moving them from the filesystem-specific __put_super() function to the generic_shutdown_super() function to maintain access to block devices during cleanup. However, this change inadvertently created a path where memory allocated for keyring structures could persist in memory when mount operations fail after the test_dummy_encryption option has been processed but before the mount completes successfully.
The technical implementation of this vulnerability involves the kernel's encryption subsystem managing cryptographic keys through keyring structures that are designed to be destroyed when filesystems are unmounted or when mount operations fail. When the test_dummy_encryption mount option is specified, the system processes this option and allocates keyring memory structures to handle the encryption context. The original code change attempted to resolve a different issue by ensuring block device access during cleanup, but this introduced the memory leak by not properly handling the destruction sequence when mount failures occur. The system processes the mount option and allocates the necessary keyring structures, but when the mount subsequently fails, the keyring destruction logic in generic_shutdown_super() executes but does not account for the fact that some keyring resources may have already been partially allocated or processed during the option handling phase.
The operational impact of this vulnerability extends beyond simple memory consumption issues, as persistent memory leaks can eventually lead to system instability, performance degradation, and potential denial of service conditions. Attackers could potentially exploit this vulnerability by repeatedly attempting mount operations with the test_dummy_encryption option, causing progressive memory exhaustion over time. The vulnerability aligns with CWE-401, which addresses improper resource management and memory leaks in software systems, and demonstrates how seemingly beneficial code changes can introduce unintended consequences in complex kernel subsystems. From an attack perspective, this vulnerability could be leveraged as part of a broader exploitation strategy to exhaust system resources, particularly in environments where filesystem mount operations are frequently performed or where the test_dummy_encryption option is commonly used for testing purposes.
The mitigation strategy for CVE-2022-49897 involves implementing a dual approach to keyring destruction that ensures proper cleanup regardless of where mount failures occur in the process. The fix requires attempting keyring destruction in both the original location within __put_super() and in the new location within generic_shutdown_super() to guarantee that all allocated resources are properly released. This approach addresses the fundamental issue by ensuring that the memory management logic accounts for all possible failure paths during mount operations, particularly when the test_dummy_encryption option is involved. The solution demonstrates principles aligned with the ATT&CK framework's resource exhaustion tactics, where proper resource management and cleanup mechanisms are essential to prevent attackers from leveraging memory leaks for sustained system compromise. System administrators should ensure that affected kernels are updated to versions containing this fix, and monitoring should be implemented to detect unusual memory consumption patterns that might indicate this vulnerability being exploited in active environments.