CVE-2026-64293 in Linux
Résumé
par VulDB • 25/07/2026
Dans le noyau Linux, la vulnérabilité suivante a été corrigée :
iommufd : Utiliser sizeof(*hdr) au lieu de sizeof(hdr) dans la lecture veventq
La vérification des limites (bound-check) dans iommufd_veventq_fops_read() pour le chemin normal vEVENT utilise sizeof(hdr) alors que le code environnant utilise sizeof(*hdr) :
if (!vevent_for_lost_events_header(cur) && sizeof(hdr) + cur->data_len > count - done) {
hdr est déclaré comme struct iommufd_vevent_header *, donc sizeof(hdr) évalue la taille du pointeur. Le code environnant utilise sizeof(*hdr) de manière cohérente :
if (done >= count || sizeof(*hdr) > count - done) {
... if (copy_to_user(buf + done, hdr, sizeof(*hdr))) {
... done += sizeof(*hdr);
struct iommufd_vevent_header fait actuellement 8 octets (deux champs __u32, flags et sequence), donc sur une architecture 64 bits (sizeof(void *) == 8), les deux expressions sont par coïncidence égales et la vérification fonctionne comme prévu.
Sur une architecture 32 bits (sizeof(void *) == 4), la vérification sous-estime l'en-tête de 4 octets : un vEVENT dont data_len provoque le dépassement de count - done avec 8 + cur->data_len, mais pas avec 4 + cur->data_len, passera la vérification. Ensuite, la boucle effectuera un copy_to_user de 8 octets d'en-tête suivis de data_len octets de charge utile, écrivant au-delà du tampon fourni par l'utilisateur.
Il s'agit également d'un bug latent pour toute future extension de struct iommufd_vevent_header dépassant sizeof(void *) sur les architectures 64 bits ; la vérification ne devrait pas dépendre du fait que le type corresponde par hasard à la largeur des pointeurs de l'hôte.
Utiliser sizeof(*hdr) afin d'être cohérent avec le reste de la fonction et la quantité réelle qui sera copiée.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.