CVE-2026-74580

Resumen

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta: vhost: restablecer la caché de metadatos del vring en la reconfiguración del vring vq -> meta_iotlb[] almacena en caché el vhost_iotlb_map que respalda cada región de metadatos del vring, y iotlb_access_ok() retorna temprano en un acierto de caché, tomando el acierto como prueba de que la región ya ha sido validada: if (vhost_vq_meta_fetch(vq, addr, len, type)) return true; La caché se restablece en VHOST_IOTLB_UPDATE y VHOST_IOTLB_INVALIDATE, en la (re)inicialización del IOTLB del dispositivo y en el restablecimiento del vq, pero no cuando VHOST_SET_VRING_ADDR reemplaza vq -> desc, vq -> avail y vq -> used, ni cuando VHOST_SET_VRING_NUM cambia los tamaños de las regiones. Con un IOTLB de dispositivo adjunto, ambos ioctls son aceptados mientras el vq está activo, y ninguno valida las direcciones en el momento del ioctl: vq_access_ok() y vq_log_used_access_ok() retornan true temprano porque las direcciones son GIOVAs, aplazando la validación al momento de la precarga. Una vez que la caché ha sido poblada, esa validación aplazada ya no se ejecuta -- vq_meta_prefetch() acierta la entrada obsoleta y retorna true -- y vhost_vq_meta_fetch() sigue traduciendo a través del mapeo antiguo como map -> addr + addr - map -> start para una dirección que el mapeo ya no cubre. vhost_copy_to_user() y vhost_copy_from_user() consumen el resultado con __copy_to_user() y __copy_from_user(), que tampoco lo verifican, por lo que una actualización posterior del anillo usado o una obtención de descriptor accede a memoria fuera de la región que el IOTLB realmente mapea. Restablecer la caché de metadatos cada vez que el vring es reconfigurado, para que las nuevas direcciones sean empujadas de vuelta a través de la ruta lenta de iotlb_access_ok().

Fuentes

• security-researchPoC

  Código C de prueba de concepto y análisis para vulnerabilidades divulgadas del kernel de Linux, incluidos los códigos fuente de exploits por CVE y el análisis técnico.