CVE-2022-49899 in Linux
Zusammenfassung
von VulDB • 13.06.2026
Im Linux-Kernel wurde folgende Schwachstelle behoben:
fscrypt: Verwendung des Keyrings-Subsystems für fscrypt_master_key beenden
Der Ansatz, die `fscrypt_master_key`-Strukturen im Dateisystem-Crypto-Bereich (`fs/crypto/`) intern als Nutzdaten von „struct key"-Objekten zu verwalten, die in einem „struct key"-Keyring enthalten sind, hat seinen Nutzen überschritten. Die ursprüngliche Idee bestand darin, den Code durch Wiederverwendung von Code aus dem Keyrings-Subsystem zu vereinfachen. Es haben sich jedoch mehrere Probleme ergeben, die nicht einfach gelöst werden können:
- Wenn eine Master-Key-Struktur zerstört wird, muss `blk_crypto_evict_key()` für alle eingebetteten schlüsselspezifischen Modi aufgerufen werden. (Dies wurde erforderlich, als die Unterstützung für Inline-Verschlüsselung hinzugefügt wurde.) Das Keyrings-Subsystem kann jedoch die Zerstörung von Keys beliebig verzögern, sogar über den Zeitpunkt hinaus, an dem das Dateisystem ausgehängt wurde. Daher gibt es derzeit keinen einfachen Weg, `blk_crypto_evict_key()` aufzurufen, wenn ein Master-Key zerstört wird. Derzeit wird dies durch Halten einer zusätzlichen Referenz auf die Anforderungswarteschlangen (`request_queue`) des Dateisystems umgangen. Es wurde jedoch übersehen, dass die `request_queue`-Referenz *nicht* garantiert, auch das entsprechende `blk_crypto_profile` zu sichern; bei Device-Mapper-Geräten mit Unterstützung für Inline-Krypto ist dies nicht der Fall. Dies kann einen Use-After-Free-Fehler verursachen.
- Wenn der letzte Inode, der einen unvollständig entfernten Master-Key verwendet hat, entfernt wird, erfolgt die Fertigstellung der Entfernung des Master-Keys durch Entfernen der Key-Struktur aus dem Keyring. Derzeit geschieht dies über `key_invalidate()`. Allerdings nimmt `key_invalidate()` das Schlüssel-Semaphor in Beschlag. Dies kann zu einem Deadlock führen, wenn es vom Shrinker aufgerufen wird, da im `fscrypt_ioctl_add_key()` Speicher mit `GFP_KERNEL` unter demselben Semaphor allokiert wird.
- Im Allgemeinen ist die Tatsache unerwünscht, dass das Keyrings-Subsystem die Zerstörung von Keys beliebig verzögern kann (durch Garbage-Collection-Verzögerung oder durch temporäre Schlüsselreferenzen in zufälligen Prozessen), da dies bedeutet, dass wir nicht streng garantieren können, dass alle Geheimnisse jemals gelöscht werden.
- Das Durchführen der Master-Key-Suchen über das Keyrings-Subsystem führt dazu, dass die LSM-Hook `key_permission` aufgerufen wird. fscrypt möchte dies nicht, da die gesamte Zugriffskontrolle für verschlüsselte Dateien so konzipiert ist, dass sie wie bei jeder anderen Datei auch über die Dateien selbst erfolgt. Der Workaround, den SELinux-Benutzer verwenden, besteht darin, ihre SELinux-Richtlinie zu ändern, um allen Domänen den Schlüssel-Suchzugriff zu gewähren. Dies funktioniert, stellt jedoch einen seltsamen zusätzlichen Schritt dar, der eigentlich nicht durchgeführt werden müsste.
Die Lösung für all diese Probleme besteht darin, die Implementierung so zu ändern, wie ich es ursprünglich hätte tun sollen: Verwenden Sie das Keyrings-Subsystem nicht mehr zur Verwaltung der `fscrypt_master_key`-Strukturen des Dateisystems. Speichern Sie sie stattdessen einfach in einer regulären Kernel-Datenstruktur und passen Sie die Referenzzählung, Synchronisierung (Locking) und Lebensdauer entsprechend an. Behalten Sie die Unterstützung für RCU-Modus-Schlüsselsuchen bei, indem Sie eine Hash-Tabelle verwenden. Ersetzen Sie `fscrypt_sb_free()` durch `fscrypt_sb_delete()`, das die Keys synchron freigibt und etwas früher während des Aushäng
If you want to get best quality of vulnerability data, you may have to visit VulDB.