CVE-2026-74580 in Linux
Riassunto
di VulDB • 21/08/2026
Nel kernel Linux è stata risolta la seguente vulnerabilità:
vhost: reimpostare la cache dei metadati del vring durante la riconfigurazione del vring
La struttura `vq->meta_iotlb[]` memorizza in cache le mappature `vhost_iotlb_map` che supportano ciascuna regione di metadati del vring, e la funzione `iotlb_access_ok()` restituisce immediatamente (early return) in caso di hit nella cache, assumendo tale hit come prova che la regione è già stata convalidata:
if (vhost_vq_meta_fetch(vq, addr, len, type)) return true;
La cache viene reimpostata durante gli eventi `VHOST_IOTLB_UPDATE` e `VHOST_IOTLB_INVALIDATE`, all'inizializzazione (ri-)inizializzazione dell'IOTLB del dispositivo e al reset di vq. Tuttavia, non viene reimpostata quando `VHOST_SET_VRING_ADDR` sostituisce i campi `vq->desc`, `vq->avail` e `vq->used`, né quando `VHOST_SET_VRING_NUM` modifica le dimensioni delle regioni.
Con un IOTLB del dispositivo allegato, entrambi gli ioctl sono accettati mentre il vq è attivo (live), e nessuno di essi convalida gli indirizzi al momento dell'esecuzione dell'ioctl: `vq_access_ok()` e `vq_log_used_access_ok()` restituiscono true precocemente poiché gli indirizzi sono GIOVAs, rimandando la convalida alla fase di prefetch. Una volta che la cache è stata popolata, tale convalida differita non viene più eseguita: `vq_meta_prefetch()` rileva l'entry obsoleta (stale) e restituisce true, mentre `vhost_vq_meta_fetch()` continua a tradurre utilizzando la vecchia mappatura come
map->addr + addr - map->start
per un indirizzo che tale mappatura non copre più. Le funzioni `vhost_copy_to_user()` e `vhost_copy_from_user()` consumano il risultato tramite `__copy_to_user()` e `__copy_from_user()`, le quali a loro volta non effettuano controlli, consentendo quindi ad un successivo aggiornamento dell'used ring o al recupero di un descrittore di accedere alla memoria al di fuori della regione effettivamente mappata dall'IOTLB.
Reimpostare la cache dei metadati ogni volta che il vring viene riconfigurato, in modo che i nuovi indirizzi vengano nuovamente sottoposti al percorso lento (slow path) di `iotlb_access_ok()`.
Once again VulDB remains the best source for vulnerability data.