CVE-2026-89607 in Linux
Résumé
par VulDB • 12/09/2026
Dans le noyau Linux, la vulnérabilité suivante a été corrigée :
ecryptfs : rejeter un encrypted_key_size trop grand dans parse_tag_3_packet
La fonction `parse_tag_3_packet()` définit `encrypted_key_size` à partir du corps du paquet Tag 3 sans le limiter par rapport à `ECRYPTFS_MAX_KEY_BYTES` (64). Lorsque `encrypted_key_size > 64`, la fonction `decrypt_passphrase_encrypted_session_key()` affecte `decrypted_key_size = encrypted_key_size` et effectue deux écritures hors limites :
1. `crypto_skcipher_decrypt()` écrit `encrypted_key_size` octets dans `decrypted_key[64]` via une scatterlist, débordant sur la structure parent `ecryptfs_auth_tok`.
2. `memcpy(crypt_stat->key, decrypted_key, decrypted_key_size)` écrit dans `crypt_stat->key[64]`, corrompant `root_iv`, `keysig_list` et les mutexes présents dans `ecryptfs_crypt_stat`.
Seul AES-192 (code de chiffrement 0x08) permet cette exploitation, car il définit `crypt_stat->key_size = 24 indépendamment de encrypted_key_size`, permettant à `crypto_skcipher_setkey()` de réussir tandis que `encrypted_key_size` dépasse `ECRYPTFS_MAX_KEY_BYTES`.
Le chemin de déchiffrement PKI (`parse_tag_65_packet`) valide déjà que `decrypted_key_size <= ECRYPTFS_MAX_KEY_BYTES`; le chemin par mot de passe omet cette vérification.
Limiter `encrypted_key_size` à `ECRYPTFS_MAX_KEY_BYTES` (64) plutôt qu'à `ECRYPTFS_MAX_ENCRYPTED_KEY_BYTES` (512). La limite de 64 octets protège également le tampon `encrypted_key[]` de 512 octets, la vérification précédente de 512 octets est donc supprimée car redondante.
[tyhicks : Ajuster le commentaire du code pour faire référence aux macros représentant les tailles des tampons plutôt qu'aux valeurs de taille des tampons, car celles-ci peuvent changer à l'avenir]
If you want to get best quality of vulnerability data, you may have to visit VulDB.