CVE-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/…

PriorityP422medium5.5CVSS 3.1

AVLACLPRLUINSUCNINAH

EPSS

0.22%

12.2th percentile

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 c

Affected

13 ranges

Vendor	Product	Version range	Fixed in
debian	linux	< linux 6.0.8-1 (bookworm)	linux 6.0.8-1 (bookworm)
linux	linux	—	—
linux	linux	>= 22d94f493bfb408fdd764f7b1d0363af2122fba5 < 391cceee6d435e616f68631e68f5b32d480b1e67	391cceee6d435e616f68631e68f5b32d480b1e67
linux	linux	>= 22d94f493bfb408fdd764f7b1d0363af2122fba5 < e6f4fd85ef1ee6ab356bfbd64df28c1cb73aee7e	e6f4fd85ef1ee6ab356bfbd64df28c1cb73aee7e
linux	linux	>= 22d94f493bfb408fdd764f7b1d0363af2122fba5 < 68d15d6558a386f46d815a6ac39edecad713a1bf	68d15d6558a386f46d815a6ac39edecad713a1bf
linux	linux	>= 22d94f493bfb408fdd764f7b1d0363af2122fba5 < d7e7b9af104c7b389a0c21eb26532511bce4b510	d7e7b9af104c7b389a0c21eb26532511bce4b510
linux	linux_kernel	>= 0 < 5.10.158-1	5.10.158-1
linux	linux_kernel	>= 0 < 6.0.8-1	6.0.8-1
linux	linux_kernel	>= 0 < 6.0.8-1	6.0.8-1
linux	linux_kernel	>= 0 < 6.0.8-1	6.0.8-1
linux	linux_kernel	>= 5.11 < 5.15.78	5.15.78
linux	linux_kernel	>= 5.16 < 6.0.8	6.0.8
linux	linux_kernel	>= 5.4 < 5.10.154	5.10.154

CVSS provenance

nvdv3.15.5MEDIUMCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

osv5.5MEDIUM

vendor_debian5.5MEDIUM

vendor_redhat5.5MEDIUM

Stop checking back — get the weekly exploitation signal.

Every Monday: what got weaponized or added to CISA KEV in the last seven days — each CVE cross-linked to its PoC, Nuclei template, and detection rule. Free, one email a week, unsubscribe in one click.