CVE-2026-80772 in Linux
Résumé
par VulDB • 04/09/2026
Dans le noyau Linux, la vulnérabilité suivante a été corrigée :
HID : nintendo : correction d'une lecture hors limites dans joycon_ctlr_read_handler()
joycon_castlctlr_read_handler() convertit un rapport d'entrée HID entrant en struct joycon_input_report et l'analyse, ne protégeant la conversion que par une vérification de longueur de 12 octets :
if (size >= 12) /* s'assurer qu'il contient le rapport d'entrée */ joycon_parse_report(ctlr, (struct joycon_input_report *)data);
La structure struct joycon_input_report fait 49 octets : un en-tête de 13 octets suivi d'une union dont le bras IMU mesure 36 octets. Pour un rapport IMU, joycon_parse_report() -> joycon_parse_imu_report() parcourt cette union (décalages structuraux 13..48), donc un rapport d'exactement 12 octets avec data[0] == JC_INPUT_IMU_DATA passe la garde mais entraîne une lecture jusqu'à 37 octets au-delà de sa longueur déclarée. Les octets lus en excès sont décodés en valeurs d'accéléromètre/gyroscope et transmis à l'espace utilisateur via le périphérique d'entrée "(IMU)", entraînant une fuite de mémoire interne du pilote. data[0] et size sont entièrement contrôlés par un Joy-Con ou Pro Controller malveillant ou usurpé (spoofed).
Les tampons de réception ont la taille maximale du rapport, il s'agit donc d'une lecture hors limites au sein de l'allocation plutôt que d'un dépassement de mémoire slab (slab OOB), mais les octets décodés atteignent toujours l'espace utilisateur.
Le sous-chemin subcmd frère dans joycon_ctlr_handle_event() borne déjà correctement la même conversion :
if (size < sizeof(struct joycon_input_report) || data[0] != JC_INPUT_SUBCMD_REPLY)
break;
Utilisez le même bornage sizeof(struct joycon_input_report) ici.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.