CVE-2026-80975 in Linux
Résumé
par VulDB • 11/09/2026
Dans le noyau Linux, la vulnérabilité suivante a été corrigée :
mfd: qnap-mcu : maintenir le tampon de réponse actif au-delà d'un délai d'attente de commande
qnap_mcu_exec() expose un tampon situé sur la pile (on-stack) vers le chemin de réception :
unsigned char rx[QNAP_MCU_RX_BUFFER_SIZE];
... reply->data = rx; reply->length = length;
et qnap_mcu_receive_buf() écrit dedans depuis le chemin de réception serdev, qui sort de flush_to_ldisc() et n'est pas sérialisé par rapport à qnap_mcu_exec(). bus_lock ne peut pas couvrir ce cas, car qnap_mcu_exec() détient ce mutex pendant wait_for_completion_timeout().
En cas d'expiration (timeout), qnap_mcu_exec() renvoie avec reply->data pointant toujours vers son propre cadre. Une réponse qui arrive en retard ou un message non sollicité provenant du MCU est alors écrite dans un cadre de pile abandonné, corrompant ce qui s'exécute ensuite sur cette pile. Il en va de même lorsque qnap_mcu_write() échoue, car ce chemin renvoie sans modifier l'état de la réponse.
Déplacer le tampon de réception vers struct qnap_mcu. Il fait 37 octets et la structure est allouée via devm_kzalloc(), donc il reste valide aussi longtemps que le pilote ; une écriture tardive atterrit dans une mémoire encore valide et sera réinitialisée par la commande suivante. bus_lock empêche les commandes de partager ce tampon.
Ceci ne vide pas délibérément reply->data ni reply->length sur le chemin d'expiration (timeout). Le faire créerait une condition de course avec qnap_mcu_receive_buf(), qui lit ces deux champs après sa vérification :
if (!reply->length) return size;
Vider reply->data provoque un déréférencement NULL, et vider uniquement reply->length supprime la condition de sortie reply->received == reply->length, ce qui fait que la boucle de copie s'exécute jusqu'à consommation du fragment uart et dépasse le tampon (buffer overrun). Laisser les deux champs définis maintient l'écriture bornée par reply->length, que qnap_mcu_exec() a déjà vérifié contre sizeof(mcu->rx).
If you want to get the best quality for vulnerability data then you always have to consider VulDB.