CVE-2022-49899

{"id": "CVE-2022-49899", "cveTags": [], "metrics": {"cvssMetricV31": [{"type": "Primary", "source": "nvd@nist.gov", "cvssData": {"scope": "UNCHANGED", "version": "3.1", "baseScore": 5.5, "attackVector": "LOCAL", "baseSeverity": "MEDIUM", "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H", "integrityImpact": "NONE", "userInteraction": "NONE", "attackComplexity": "LOW", "availabilityImpact": "HIGH", "privilegesRequired": "LOW", "confidentialityImpact": "NONE"}, "impactScore": 3.6, "exploitabilityScore": 1.8}]}, "published": "2025-05-01T15:16:14.953", "references": [{"url": "https://git.kernel.org/stable/c/391cceee6d435e616f68631e68f5b32d480b1e67", "tags": ["Patch"], "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}, {"url": "https://git.kernel.org/stable/c/68d15d6558a386f46d815a6ac39edecad713a1bf", "tags": ["Patch"], "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}, {"url": "https://git.kernel.org/stable/c/d7e7b9af104c7b389a0c21eb26532511bce4b510", "tags": ["Patch"], "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}, {"url": "https://git.kernel.org/stable/c/e6f4fd85ef1ee6ab356bfbd64df28c1cb73aee7e", "tags": ["Patch"], "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}], "vulnStatus": "Analyzed", "weaknesses": [{"type": "Primary", "source": "nvd@nist.gov", "description": [{"lang": "en", "value": "NVD-CWE-noinfo"}]}], "descriptions": [{"lang": "en", "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nfscrypt: stop using keyrings subsystem for fscrypt_master_key\n\nThe approach of fs/crypto/ internally managing the fscrypt_master_key\nstructs as the payloads of \"struct key\" objects contained in a\n\"struct key\" keyring has outlived its usefulness. The original idea was\nto simplify the code by reusing code from the keyrings subsystem.\nHowever, several issues have arisen that can't easily be resolved:\n\n- When a master key struct is destroyed, blk_crypto_evict_key() must be\n called on any per-mode keys embedded in it. (This started being the\n case when inline encryption support was added.) Yet, the keyrings\n subsystem can arbitrarily delay the destruction of keys, even past the\n time the filesystem was unmounted. Therefore, currently there is no\n easy way to call blk_crypto_evict_key() when a master key is\n destroyed. Currently, this is worked around by holding an extra\n reference to the filesystem's request_queue(s). But it was overlooked\n that the request_queue reference is *not* guaranteed to pin the\n corresponding blk_crypto_profile too; for device-mapper devices that\n support inline crypto, it doesn't. This can cause a use-after-free.\n\n- When the last inode that was using an incompletely-removed master key\n is evicted, the master key removal is completed by removing the key\n struct from the keyring. Currently this is done via key_invalidate().\n Yet, key_invalidate() takes the key semaphore. This can deadlock when\n called from the shrinker, since in fscrypt_ioctl_add_key(), memory is\n allocated with GFP_KERNEL under the same semaphore.\n\n- More generally, the fact that the keyrings subsystem can arbitrarily\n delay the destruction of keys (via garbage collection delay, or via\n random processes getting temporary key references) is undesirable, as\n it means we can't strictly guarantee that all secrets are ever wiped.\n\n- Doing the master key lookups via the keyrings subsystem results in the\n key_permission LSM hook being called. fscrypt doesn't want this, as\n all access control for encrypted files is designed to happen via the\n files themselves, like any other files. The workaround which SELinux\n users are using is to change their SELinux policy to grant key search\n access to all domains. This works, but it is an odd extra step that\n shouldn't really have to be done.\n\nThe fix for all these issues is to change the implementation to what I\nshould have done originally: don't use the keyrings subsystem to keep\ntrack of the filesystem's fscrypt_master_key structs. Instead, just\nstore them in a regular kernel data structure, and rework the reference\ncounting, locking, and lifetime accordingly. Retain support for\nRCU-mode key lookups by using a hash table. Replace fscrypt_sb_free()\nwith fscrypt_sb_delete(), which releases the keys synchronously and runs\na bit earlier during unmount, so that block devices are still available.\n\nA side effect of this patch is that neither the master keys themselves\nnor the filesystem keyrings will be listed in /proc/keys anymore.\n(\"Master key users\" and the master key users keyrings will still be\nlisted.) However, this was mostly an implementation detail, and it was\nintended just for debugging purposes. I don't know of anyone using it.\n\nThis patch does *not* change how \"master key users\" (->mk_users) works;\nthat still uses the keyrings subsystem. That is still needed for key\nquotas, and changing that isn't necessary to solve the issues listed\nabove. If we decide to change that too, it would be a separate patch.\n\nI've marked this as fixing the original commit that added the fscrypt\nkeyring, but as noted above the most important issue that this patch\nfixes wasn't introduced until the addition of inline encryption support."}, {"lang": "es", "value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: fscrypt: dejar de usar el subsistema de llaveros para fscrypt_master_key. El enfoque de fs/crypto/, que gestionaba internamente las estructuras fscrypt_master_key como payloads de objetos \"struct key\" contenidos en un llavero \"struct key\", ha dejado de ser \u00fatil. La idea original era simplificar el c\u00f3digo reutilizando c\u00f3digo del subsistema de llaveros. Sin embargo, han surgido varios problemas que no se pueden resolver f\u00e1cilmente: - Cuando se destruye una estructura de clave maestra, se debe llamar a blk_crypto_evict_key() en cualquier clave por modo incrustada en ella. (Esto empez\u00f3 a ocurrir cuando se a\u00f1adi\u00f3 la compatibilidad con el cifrado en l\u00ednea). Sin embargo, el subsistema de llaveros puede retrasar arbitrariamente la destrucci\u00f3n de claves, incluso despu\u00e9s de que se desmontara el sistema de archivos. Por lo tanto, actualmente no hay una forma sencilla de llamar a blk_crypto_evict_key() cuando se destruye una clave maestra. Actualmente, esto se soluciona manteniendo una referencia adicional a las colas de solicitudes (solicitudes) del sistema de archivos. Sin embargo, se pas\u00f3 por alto que la referencia a la cola de solicitudes *no* garantiza que tambi\u00e9n fije el perfil blk_crypto_profile correspondiente; para los dispositivos con mapeador de dispositivos que admiten criptograf\u00eda en l\u00ednea, no lo hace. Esto puede causar un uso despu\u00e9s de la liberaci\u00f3n. - Cuando se expulsa el \u00faltimo inodo que usaba una clave maestra eliminada de forma incompleta, la eliminaci\u00f3n de la clave maestra se completa eliminando la estructura de la clave del anillo de claves. Actualmente, esto se realiza mediante key_invalidate(). Sin embargo, key_invalidate() toma el sem\u00e1foro de la clave. Esto puede generar un bloqueo al ser llamado desde el reductor, ya que en fscrypt_ioctl_add_key(), la memoria se asigna con GFP_KERNEL bajo el mismo sem\u00e1foro. En t\u00e9rminos m\u00e1s generales, el hecho de que el subsistema de llaveros pueda retrasar arbitrariamente la destrucci\u00f3n de claves (mediante un retraso en la recolecci\u00f3n de basura o mediante procesos aleatorios que obtienen referencias temporales a las claves) es indeseable, ya que significa que no podemos garantizar estrictamente que todos los secretos se borren. Realizar las b\u00fasquedas de la clave maestra a trav\u00e9s del subsistema de llaveros resulta en la llamada al gancho LSM key_permission. fscrypt no desea esto, ya que todo el control de acceso a los archivos cifrados est\u00e1 dise\u00f1ado para realizarse a trav\u00e9s de los propios archivos, como cualquier otro archivo. La soluci\u00f3n alternativa que utilizan los usuarios de SELinux es cambiar su pol\u00edtica de SELinux para otorgar acceso de b\u00fasqueda de claves a todos los dominios. Esto funciona, pero es un paso adicional extra\u00f1o que realmente no deber\u00eda ser necesario. La soluci\u00f3n para todos estos problemas es cambiar la implementaci\u00f3n a lo que deber\u00eda haber hecho originalmente: no usar el subsistema de llaveros para realizar un seguimiento de las estructuras fscrypt_master_key del sistema de archivos. En su lugar, simplemente almac\u00e9nelos en una estructura de datos de kernel normal y modifique el recuento de referencias, el bloqueo y la duraci\u00f3n seg\u00fan corresponda. Mantenga la compatibilidad con las b\u00fasquedas de claves en modo RCU mediante una tabla hash. Reemplace fscrypt_sb_free() por fscrypt_sb_delete(), que libera las claves sincr\u00f3nicamente y se ejecuta un poco antes durante el desmontaje, para que los dispositivos de bloque sigan disponibles. Un efecto secundario de este parche es que ni las claves maestras ni los conjuntos de claves del sistema de archivos aparecer\u00e1n en /proc/keys. (Los \"usuarios de clave maestra\" y los conjuntos de claves de los usuarios de clave maestra seguir\u00e1n apareciendo). Sin embargo, esto era principalmente un detalle de implementaci\u00f3n y estaba destinado \u00fanicamente a fines de depuraci\u00f3n. No conozco a nadie que lo use. Este parche *no* cambia el funcionamiento de los \"usuarios de clave maestra\" (->mk_users)--- truncado ----"}], "lastModified": "2025-05-07T13:19:06.700", "configurations": [{"nodes": [{"negate": false, "cpeMatch": [{"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "vulnerable": true, "matchCriteriaId": "0910F02E-5A73-45B6-9ABC-05EABA85090A", "versionEndExcluding": "5.10.154", "versionStartIncluding": "5.4"}, {"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "vulnerable": true, "matchCriteriaId": "AB8B27B9-B41B-42D5-AE67-0A89A8A8EEB1", "versionEndExcluding": "5.15.78", "versionStartIncluding": "5.11"}, {"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "vulnerable": true, "matchCriteriaId": "EC9A754E-625D-42F3-87A7-960D643E2867", "versionEndExcluding": "6.0.8", "versionStartIncluding": "5.16"}], "operator": "OR"}]}], "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}