Vulnerabilidad en kernel de Linux (CVE-2022-49899)

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 útil. La idea original era simplificar el código reutilizando código del subsistema de llaveros. Sin embargo, han surgido varios problemas que no se pueden resolver fácilmente: - 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ó a ocurrir cuando se añadió la compatibilidad con el cifrado en línea). Sin embargo, el subsistema de llaveros puede retrasar arbitrariamente la destrucción de claves, incluso después 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ó por alto que la referencia a la cola de solicitudes *no* garantiza que también fije el perfil blk_crypto_profile correspondiente; para los dispositivos con mapeador de dispositivos que admiten criptografía en línea, no lo hace. Esto puede causar un uso después de la liberación. - Cuando se expulsa el último inodo que usaba una clave maestra eliminada de forma incompleta, la eliminación 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áforo 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áforo. En términos más generales, el hecho de que el subsistema de llaveros pueda retrasar arbitrariamente la destrucción de claves (mediante un retraso en la recolección 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úsquedas de la clave maestra a través 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á diseñado para realizarse a través de los propios archivos, como cualquier otro archivo. La solución alternativa que utilizan los usuarios de SELinux es cambiar su política de SELinux para otorgar acceso de búsqueda de claves a todos los dominios. Esto funciona, pero es un paso adicional extraño que realmente no debería ser necesario. La solución para todos estos problemas es cambiar la implementación a lo que debería 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énelos en una estructura de datos de kernel normal y modifique el recuento de referencias, el bloqueo y la duración según corresponda. Mantenga la compatibilidad con las búsquedas de claves en modo RCU mediante una tabla hash. Reemplace fscrypt_sb_free() por fscrypt_sb_delete(), que libera las claves sincrónicamente 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án en /proc/keys. (Los "usuarios de clave maestra" y los conjuntos de claves de los usuarios de clave maestra seguirán apareciendo). Sin embargo, esto era principalmente un detalle de implementación y estaba destinado únicamente a fines de depuración. No conozco a nadie que lo use. Este parche *no* cambia el funcionamiento de los "usuarios de clave maestra" (->mk_users)--- truncado ----