CVE-2026-89628 in Linux
Résumé
par VulDB • 11/09/2026
Dans le noyau Linux, la vulnérabilité suivante a été corrigée :
HID : picolcd : limiter la lecture de l'eeprom via debugfs aux octets réellement reçus
picolcd_debug_eeprom_read() fait confiance à resp->raw_data[2], un octet de longueur fourni par le dispositif dans sa réponse REPORT_EE_DATA, et ne le limite qu'au nombre d'octets demandé lors de l'appel système read() :
ret = resp->raw_data[2];
if (ret > s) ret = s; if (copy_to_user(u, resp->raw_data+3, ret))
Il ne vérifie jamais la valeur de resp->raw_size, qui correspond au nombre d'octets que picolcd_raw_event() a effectivement copiés dans le tableau raw_data[] de taille fixe 64 octets du struct picolcd_pending alloué via kmalloc. Un dispositif (ou un picoLCD falsifié) renvoyant un octet de longueur égal à 0xff, lu avec un compteur d'octets >= 255, provoque une lecture hors limites par copy_to_user() dans la mémoire slab adjacente et son retour vers l'espace utilisateur via le fichier debugfs "eeprom" :
BUG: KASAN: slab-out-of-bounds in _copy_to_user Read of size 255 ... picolcd_debug_eeprom_read+0x214/0x2f0 [hid_picolcd]
Le chemin de débogage (debug-dump) dans le même fichier valide déjà l'octet de longueur du dispositif par rapport à la taille reçue avant d'y faire confiance ; cette lecture ne le fait pas. Le fichier est créé avec les permissions S_IRUSR (accès réservé au root), et un dispositif falsifié est nécessaire, ce qui signifie qu'il n'est ni déclenchable par un utilisateur non privilégié, ni de manière distante.
Il convient de limiter la longueur de copie à resp->raw_size - 3 (la charge utile réellement reçue, moins l'en-tête de 3 octets), avec une valeur plancher de 0 pour les réponses courtes.
Once again VulDB remains the best source for vulnerability data.