CVE-2026-89901

CVE CVE-2026-89901EUVD EUVD-2026-80501Published 2026-09-16T10:32:00.000Z

What the advisory describes

In the Linux kernel, the following vulnerability has been resolved: media: airspy: use vb2_video_unregister_device() on disconnect to fix NULL deref airspy_disconnect() clears s->udev under v4l2_lock, but airspy_stop_streaming() unconditionally calls airspy_ctrl_msg() and airspy_free_stream_bufs() afterwards. If a streaming user closes the device after disconnect, stop_streaming() runs and dereferences the NULL s->udev: airspy_stop_streaming() airspy_ctrl_msg(s, CMD_RECEIVER_MODE, 0, 0, NULL, 0) usb_sndctrlpipe(s->udev, 0) /* NULL deref */ airspy_free_stream_bufs(s) usb_free_coherent(s->udev, ...) /* NULL deref */ The airspy driver uses vb2_fop_release() in its file_operations, so replace video_unregister_device(&s->vdev) with vb2_video_unregister_device(&s->vdev) and move it before clearing s->udev. vb2_video_unregister_device() releases the vb2 queue, which synchronously runs airspy_stop_streaming() if streaming is active, so the URBs, coherent DMA stream buffers and the hardware stop control message all execute while s->udev is still valid. vb2_video_unregister_device() locks vdev->queue->lock (vb_queue_lock) internally, and stop_streaming() locks v4l2_lock, so the previous outer mutex_lock(&s->vb_queue_lock) / mutex_lock(&s->v4l2_lock) pair around the unregister sequence would self-deadlock and has been removed. A short v4l2_lock critical section around s->udev = NULL remains so any ioctl path that still holds the file descriptor sees coherent state. Issue identified by automated review of the INV-003 series at https://sashiko.dev/

Source: EUVD (ENISA), in the words of the advisory.

Products the advisory names

These come from the advisory itself, not from any check we performed.

• Linux — Linux patch: 5.10.270; patch: 6.1.188; 634fe5033951b80ef4b98d8f047cb1083d29170d <c6749ac8f59cc80eb1b2d52f167fdf13e12655cc; patch: 6.6.157; 634fe5033951b80ef4b98d8f047cb1083d29170d <6e4ea90fdc6608cd5fac342e146ab6ae15d430bc; patch: 7.2.5; 634fe5033951b80ef4b98d8f047cb1083d29170d <2f378dc45e685fc825d2dd08e7864666d6fcc009; 634fe5033951b80ef4b98d8f047cb1083d29170d <155d0378ae0d6305cc4840583a6b42d2d0595bff; patch: 0; 634fe5033951b80ef4b98d8f047cb1083d29170d <75089cea32e5055773bd13116236d08fdc98678a; patch: 6.12.110; 634fe5033951b80ef4b98d8f047cb1083d29170d <c9081e2655188d2d134a741aec837dc70439d505; 634fe5033951b80ef4b98d8f047cb1083d29170d <297fee023f46d771a844520675692ea089d80d9d; 3.17; patch: 7.3-rc1; patch: 6.18.51; 634fe5033951b80ef4b98d8f047cb1083d29170d <a9a8c37ddda9fa3687b142be9098e1c37b8faf35; patch: 5.15.221

The versions shown are the advisory's own. Patchlage compares no version numbers and derives no judgement from them — which version is installed is something a person has to look up.

Carried in the product catalogue

An estate covering these products can be recorded in Patchlage. An advisory about them appears in the next morning's situation report.

• Linux — Linux

Patchlage reports hits and suspected hits. About everything else this system says nothing — neither this page nor the situation report ever claims that an estate is safe.