CVE-2022-49899: Vulnerability in Linux Linux

Severity: highType: vulnerabilityCVE-2022-49899

In the Linux kernel, the following vulnerability has been resolved: fscrypt: stop using keyrings subsystem for fscrypt_master_key The approach of fs/crypto/ internally managing the fscrypt_master_key structs as the payloads of "struct key" objects contained in a "struct key" keyring has outlived its usefulness. The original idea was to simplify the code by reusing code from the keyrings subsystem. However, several issues have arisen that can't easily be resolved: - When a master key struct is destroyed, blk_crypto_evict_key() must be called on any per-mode keys embedded in it. (This started being the case when inline encryption support was added.) Yet, the keyrings subsystem can arbitrarily delay the destruction of keys, even past the time the filesystem was unmounted. Therefore, currently there is no easy way to call blk_crypto_evict_key() when a master key is destroyed. Currently, this is worked around by holding an extra reference to the filesystem's request_queue(s). But it was overlooked that the request_queue reference is *not* guaranteed to pin the corresponding blk_crypto_profile too; for device-mapper devices that support inline crypto, it doesn't. This can cause a use-after-free. - When the last inode that was using an incompletely-removed master key is evicted, the master key removal is completed by removing the key struct from the keyring. Currently this is done via key_invalidate(). Yet, key_invalidate() takes the key semaphore. This can deadlock when called from the shrinker, since in fscrypt_ioctl_add_key(), memory is allocated with GFP_KERNEL under the same semaphore. - More generally, the fact that the keyrings subsystem can arbitrarily delay the destruction of keys (via garbage collection delay, or via random processes getting temporary key references) is undesirable, as it means we can't strictly guarantee that all secrets are ever wiped. - Doing the master key lookups via the keyrings subsystem results in the key_permission LSM hook being called. fscrypt doesn't want this, as all access control for encrypted files is designed to happen via the files themselves, like any other files. The workaround which SELinux users are using is to change their SELinux policy to grant key search access to all domains. This works, but it is an odd extra step that shouldn't really have to be done. The fix for all these issues is to change the implementation to what I should have done originally: don't use the keyrings subsystem to keep track of the filesystem's fscrypt_master_key structs. Instead, just store them in a regular kernel data structure, and rework the reference counting, locking, and lifetime accordingly. Retain support for RCU-mode key lookups by using a hash table. Replace fscrypt_sb_free() with fscrypt_sb_delete(), which releases the keys synchronously and runs a bit earlier during unmount, so that block devices are still available. A side effect of this patch is that neither the master keys themselves nor the filesystem keyrings will be listed in /proc/keys anymore. ("Master key users" and the master key users keyrings will still be listed.) However, this was mostly an implementation detail, and it was intended just for debugging purposes. I don't know of anyone using it. This patch does *not* change how "master key users" (->mk_users) works; that still uses the keyrings subsystem. That is still needed for key quotas, and changing that isn't necessary to solve the issues listed above. If we decide to change that too, it would be a separate patch. I've marked this as fixing the original commit that added the fscrypt keyring, but as noted above the most important issue that this patch fixes wasn't introduced until the addition of inline encryption support.

AI Analysis

Technical Summary

CVE-2022-49899 addresses a vulnerability in the Linux kernel's fscrypt subsystem, specifically related to the management of the fscrypt_master_key structures used for filesystem encryption. Originally, these master keys were managed as payloads within the keyrings subsystem, which was intended to simplify code reuse. However, this design introduced several critical issues. Firstly, the keyrings subsystem can delay the destruction of keys arbitrarily, even after the filesystem is unmounted, which complicates the timely eviction of per-mode keys via blk_crypto_evict_key(). This delay can lead to use-after-free conditions, especially for device-mapper devices supporting inline encryption, where the request_queue reference does not guarantee pinning of the blk_crypto_profile. Secondly, the removal of master keys involves key_invalidate(), which takes a key semaphore and can cause deadlocks when called from the shrinker due to memory allocations under the same semaphore in fscrypt_ioctl_add_key(). Thirdly, the garbage collection and temporary references in the keyrings subsystem prevent strict guarantees that all secrets are wiped promptly. Lastly, using the keyrings subsystem triggers the key_permission LSM hook, which is undesirable for fscrypt since access control is intended to be managed by the filesystem itself. The patch resolves these issues by removing the dependency on the keyrings subsystem for managing fscrypt_master_key structs, instead storing them in a dedicated kernel data structure with reworked reference counting, locking, and lifecycle management. This change also removes the listing of master keys and filesystem keyrings from /proc/keys, which was mainly a debugging feature. The patch retains the use of the keyrings subsystem for master key users to maintain key quotas. Overall, this fix improves security by preventing use-after-free vulnerabilities, deadlocks, and unintended access control interactions, while ensuring more reliable key lifecycle management in the Linux kernel's filesystem encryption.

Potential Impact

For European organizations, this vulnerability primarily affects systems running Linux kernels that implement fscrypt with inline encryption support, which is common in modern enterprise and cloud environments. Exploitation could lead to use-after-free conditions, potentially allowing local attackers or compromised processes to access or manipulate encryption keys improperly, undermining the confidentiality and integrity of encrypted data. Deadlocks caused by the vulnerability could also lead to denial-of-service conditions, impacting system availability. Given the widespread use of Linux in servers, cloud infrastructure, and embedded devices across Europe, this vulnerability could affect critical sectors such as finance, healthcare, government, and telecommunications. The inability to guarantee timely wiping of encryption keys may increase the risk of key leakage or unauthorized data access, particularly in multi-tenant or shared environments. Although no known exploits are reported in the wild, the technical complexity and kernel-level nature of the vulnerability mean that sophisticated attackers could leverage it to compromise encrypted data or disrupt services, posing significant risks to data protection and regulatory compliance under frameworks like GDPR.

Mitigation Recommendations

European organizations should prioritize updating their Linux kernel versions to include the patch that removes the fscrypt_master_key management from the keyrings subsystem. Kernel upgrades should be tested and deployed promptly, especially on systems handling sensitive encrypted data. Additionally, organizations should audit their use of inline encryption and fscrypt features to ensure they are running supported and patched kernel versions. Monitoring kernel logs for unusual keyring or fscrypt-related errors may help detect attempts to exploit related issues. For environments using SELinux, review and adjust policies to avoid unnecessary permissions that could exacerbate key access risks. Implement strict access controls and minimize local user privileges to reduce the attack surface. Where possible, isolate critical workloads and encrypted filesystems to limit the impact of potential kernel-level vulnerabilities. Finally, maintain regular backups and incident response plans to mitigate potential data loss or service disruption resulting from exploitation attempts.