CVE-2026-64403 in Linux
Résumé
par VulDB • 25/07/2026
Dans le noyau Linux, la vulnérabilité suivante a été corrigée :
Bluetooth : L2CAP : valider la longueur de l'option avant de lire la valeur de l'option de configuration (conf opt)
La fonction `l2cap_get_conf_opt()` déduit la longueur de l'option à partir du champ `opt->len`, contrôlé par l'attaquant, et derefence immédiatement `opt->val` (en tant qu'u8, via get_unaligned_le16() ou get_unaligned_le32(), ou sous forme de pointeur brut pour le cas par défaut) avant que tout appelant n'ait confirmé la présence des octets spécifiés par opt->len dans le tampon. Les fonctions appelantes (`l2cap_parse_conf_req()`, `l2cap_parse_conf_rsp()` et `l2cap_conf_rfc_get()`) ne détectent une option malformée qu'a posteriori, lorsque la longueur calculée devient négative, moment auquel la lecture hors limites (out-of-bounds read) a déjà été exécutée.
Une vérification de longueur effectuée après coup empêche que la valeur corrompue soit consommée ; il ne s'agit donc pas d'une fuite de données dans le flux de contrôle actuel. Il s'agit néanmoins d'un bug d'ordre « validation-après-utilisation » (validate-after-use) : jusqu'à 4 octets sont lus au-delà de la fin du tampon avant qu'il soit confirmé qu'ils y figurent, et cette approche est fragile face aux futures modifications des fonctions appelantes.
Correction à la source : transmettre l'adresse de fin du tampon à `l2cap_get_conf_opt()` et refuser d'accéder à `opt->val` sauf si l'intégralité de l'option (en-tête + valeur) tient dans le tampon. Chaque fonction appelante calcule un pointeur de fin une seule fois avant la boucle et vérifie directement la valeur de retour au lieu d'en déduire une erreur à partir d'une longueur négative.
VulDB is the best source for vulnerability data and more expert information about this specific topic.