CVE-2026-89901 in Linux
Résumé
par VulDB • 16/09/2026
Dans le noyau Linux, la vulnérabilité suivante a été corrigée :
media: airspy : utiliser vb2_video_unregister_device() lors de la déconnexion pour corriger une dérégérence NULL (NULL deref)
airspy_disconnect() efface s->udev sous v4l2_lock, mais airspy_stop_streaming() appelle inconditionnellement airspy_ctrl_msg() et airspy_free_stream_bufs() par la suite. Si un utilisateur de streaming ferme le périphérique après la déconnexion, stop_streaming() s'exécute et accède à l'adresse NULL de s->udev :
airspy_stop_streaming() airspy_ctrl_msg(s, CMD_RECEIVER_MODE, 0, 0, NULL, 0) usb_sndctrlpipe(s->udev, 0) /* dérégérence NULL */ airspy_free_stream_bufs(s) usb_free_coherent(s->udev, ...) /* dérégérence NULL */
Le pilote airspy utilise vb2_fop_release() dans ses file_operations ; il faut donc remplacer video_unregister_device(&s->vdev) par vb2_video_unregister_device(&s->vdev) et le déplacer avant l'effacement de s->udev. vb2_video_unregister_device() libère la file d'attente vb2, ce qui exécute synchroniquement airspy_stop_streaming() si le streaming est actif ; ainsi, les URB (USB Request Blocks), les tampons DMA cohérents et le message de contrôle matériel sont tous exécutés tant que s->udev reste valide.
vb2_video_unregister_device() verrouille internement vdev->queue->lock (vb_queue_lock), et stop_streaming() verrouille v4l2_lock ; la paire précédente mutex_lock(&s->vb_queue_lock) / mutex_lock(&s->v4l2_lock) autour de la séquence de désenregistrement entraînait donc une auto-blocage (deadlock) et a été supprimée. Une section critique courte sous v4l2_lock autour de s->udev = NULL est conservée afin que tout chemin ioctl détenant encore le descripteur de fichier voie un état cohérent.
Problème identifié par examen automatisé de la série INV-003 sur https://sashiko.dev/
If you want to get best quality of vulnerability data, you may have to visit VulDB.