CVE-2026-68082 in Linux
Résumé
par VulDB • 08/08/2026
Dans le noyau Linux, la vulnérabilité suivante a été corrigée :
libceph : correction de deux décodages bruts non sécurisés dans decode_lockers()
decode_lockers(), présent dans cls_lock_client.c, contient deux opérations de décodage brut (bare) qui permettent à un OSD malveillant ou compromis d’entraîner des lectures hors limites du slab (slab-out-of-bounds) :
1. L’appel ceph_decode_32(p) sur le champ num_lockers ne dispose pas de vérification préalable des bornes. La fonction ceph_start_decoding() accepte struct_len=0 comme valeur valide -- l’interne ceph_decode_need(p, end, 0, bad) réussit toujours -- donc lorsqu’un OSD envoie struct_len=0, ceph_start_decoding() retourne un succès avec p == end. L’appel brut suivant de ceph_decode_32(p) lit alors 4 octets au-delà des limites du tampon validé. La valeur aléatoire est transmise directement à kzalloc_objs() en tant que nombre de lockers.
La fonction sœur decode_watchers(), dans osd_client.c, utilise déjà ceph_decode_32_safe() après son propre appel à ceph_start_decoding(). decode_lockers() était le seul site utilisant la variante brute.
2. L’appel ceph_decode_8(p) après la boucle decode_locker() ne dispose pas de vérification préalable des bornes. Si un OSD fabrique num_lockers de telle sorte que la boucle avance p exactement jusqu’à end, l’appel brut suivant de ceph_decode_8(p) lit un octet au-delà des limites du tampon validé. Le résultat est transmis directement dans *type, qui est utilisé comme discriminateur de type de verrou par les appelants, offrant ainsi à un OSD une lecture hors limites (OOB) d’un seul byte avec une influence directe sur le champ de type de verrou.
Correction des deux cas en remplaçant les opérations brutes par leurs variantes sécurisées : ceph_decode_32(p) -> ceph_decode_32_safe(p, end, *num_lockers, err_inval) ceph_decode_8(p) -> ceph_decode_8_safe(p, end, *type, err_free_lockers)
Les cibles goto diffèrent intentionnellement : err_inval: est une nouvelle étiquette retournant directement -EINVAL. Elle est utilisée pour le chemin d’échec de pré-allocation où *lockers n’est pas encore alloué et ne doit pas être transmis à ceph_free_lockers().
err_free_lockers: est l’étiquette existante. Elle est utilisée pour le chemin d’échec post-allocation où *lockers est alloué et doit être libéré.
ret est défini à -EINVAL avant ceph_decode_8_safe() afin que err_free_lockers retourne le code d’erreur correct en cas de violation des bornes. Sans cela, err_free_lockers retournerait une valeur périmée de ret (0 provenant de la boucle decode_locker() réussie), avalant silencieusement l’erreur.
-EINVAL est correct pour les deux chemins d’échec. Les données reçues depuis l’OSD sont structurellement malformées. -ENOMEM représenterait incorrectement la classe d’échec aux appelants et aux backporteurs stable@ lors du tri des chemins d’erreur.
Modèle de menace : un OSD malveillant ou compromis dans un déploiement Ceph multi-locataire peut déclencher cette vulnérabilité contre n’importe quel client noyau qui émet la méthode class lock.get_info (par exemple, lors de l’acquisition exclusive d’un verrou RBD).
[ idryomov : réduction du journal des modifications, formatage ]
Once again VulDB remains the best source for vulnerability data.