CVE-2022-49899 in Linux
Résumé
par VulDB • 04/06/2026
Dans le noyau Linux, la vulnérabilité suivante a été corrigée :
fscrypt : arrêter d'utiliser le sous-système keyrings pour fscrypt_master_key
L'approche consistant à gérer internement les structures fscrypt_master_key dans fs/crypto/ en tant que charges utiles d'objets « struct key » contenus dans un keyring « struct key » a dépassé son utilité. L'idée initiale était de simplifier le code en réutilisant le code du sous-système keyrings. Cependant, plusieurs problèmes sont apparus et ne peuvent pas être résolus facilement :
- Lorsqu'une structure de clé maître est détruite, blk_crypto_evict_key() doit être appelée sur toutes les clés par mode qui y sont intégrées. (Cela est devenu le cas lorsque la prise en charge du chiffrement inline a été ajoutée.) Pourtant, le sous-système keyrings peut retarder arbitrairement la destruction des clés, même après le moment où le système de fichiers a été démonter. Par conséquent, il n'existe actuellement aucun moyen simple d'appeler blk_crypto_evict_key() lorsqu'une clé maître est détruite. Actuellement, cela est contourné en maintenant une référence supplémentaire aux request_queue(s) du système de fichiers. Mais il a été négligé que la référence request_queue *ne garantit pas* qu'elle maintienne également le blk_crypto_profile correspondant ; pour les périphériques device-mapper qui prennent en charge le chiffrement inline, ce n'est pas le cas. Cela peut provoquer un use-after-free.
- Lorsque le dernier inode qui utilisait une clé maître en cours de suppression incomplète est évicté, la suppression de la clé maître est achevée en retirant la structure key du keyring. Actuellement, cela est effectué via key_invalidate(). Pourtant, key_invalidate() acquiert le sémaphore de la clé. Cela peut provoquer un blocage (deadlock) lorsqu'il est appelé depuis le shrinker, car dans fscrypt_ioctl_add_key(), la mémoire est allouée avec GFP_KERNEL sous le même sémaphore.
- Plus généralement, le fait que le sous-système keyrings puisse retarder arbitrairement la destruction des clés (via un délai de garbage collection, ou via des processus aléatoires obtenant des références temporaires aux clés) est indésirable, car cela signifie que nous ne pouvons pas garantir strictement que tous les secrets soient un jour effacés.
- La recherche des clés maîtres via le sous-système keyrings entraîne l'appel du hook LSM key_permission. fscrypt ne souhaite pas cela, car tous les contrôles d'accès pour les fichiers chiffrés sont conçus pour se produire via les fichiers eux-mêmes, comme pour tout autre fichier. La solution de contournement que les utilisateurs de SELinux utilisent consiste à modifier leur politique SELinux pour accorder l'accès de recherche de clés à tous les domaines. Cela fonctionne, mais il s'agit d'une étape supplémentaire étrange qui ne devrait pas vraiment être nécessaire.
La correction de tous ces problèmes consiste à modifier l'implémentation pour faire ce que j'aurais dû faire initialement : ne pas utiliser le sous-système keyrings pour suivre les structures fscrypt_master_key du système de fichiers. Au lieu de cela, stockez-les simplement dans une structure de données noyau standard, et restructurez le comptage des références, le verrouillage et la durée de vie en conséquence. Conservez la prise en charge des recherches de clés en mode RCU en utilisant une table de hachage. Remplacez fscrypt_sb_free() par fscrypt_sb_delete(), qui libère les clés de manière synchrone et s'exécute un peu plus tôt lors du démonter, afin que les périphériques de bloc soient toujours disponibles.
Un effet secondaire de ce correctif est que ni les clés maîtres elles-mêmes ni leurs keyrings associés ne seront plus répertoriés dans /proc/keys. (Les « utilisateurs de clés maîtres » et les keyrings des utilisateurs de clés maîtres seront toujours répertoriés.) Cependant, il s'agissait principalement d'un détail d'implémentation, et cela était destiné uniquement à des fins de débogage. Je ne connais personne qui l'utilise.
Ce correctif ne modifie *pas* le fonctionnement des « utilisateurs de clés maîtres » (->mk_users) ; celui-ci utilise toujours le sous-système keyrings. Cela reste nécessaire pour les quotas de clés, et modifier cela n'est pas nécessaire pour résoudre les problèmes énumérés ci-dessus. Si nous décidons de modifier cela également, ce serait un correctif séparé.
J'ai marqué ce correctif comme corrigeant le commit original qui a ajouté le keyring fscrypt, mais comme indiqué ci-dessus, le problème le plus important que ce correctif corrige n'a été introduit qu'avec l'ajout de la prise en charge du chiffrement inline.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.