https://vulnerability.circl.lu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Mon, 28 Sep 2026 23:34:28 +0000 https://vulnerability.circl.lu/vuln/cve-2026-31576 <p><strong>Affected:</strong> Linux</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>media: hackrf: fix to not free memory after the device is registered in hackrf_probe()</p> <p>In hackrf driver, the following race condition occurs: ``` CPU0 CPU1 hackrf_probe() kzalloc(); // alloc hackrf_dev .... v4l2_device_register(); .... fd = sys_open(&#34;/path/to/dev&#34;); // open hackrf fd .... v4l2_device_unregister(); .... kfree(); // free hackrf_dev .... sys_ioctl(fd, ...); v4l2_ioctl(); video_is_registered() // UAF!! .... sys_close(fd); v4l2_release() // UAF!! hackrf_video_release() kfree(); // DFB!! ```</p> <p>When a V4L2 or video device is unregistered, the device node is removed so new open() calls are blocked.</p> <p>However, file descriptors that are already open-and any in-flight I/O-do not terminate immediately; they remain valid until the last reference is dropped and the driver&#39;s release() is invoked.</p> <p>Therefore, freeing device memory on the error path after hackrf_probe() has registered dev it will lead to a race to use-after-free vuln, since those already-open handles haven&#39;t been released yet.</p> <p>And since release() free memory too, race to use-after-free and double-free vuln occur.</p> <p>To prevent this, if device is registered from probe(), it should be modified to free memory only through release() rather than calling kfree() directly.</p> <p><strong>Affected:</strong> Linux</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>media: hackrf: fix to not free memory after the device is registered in hackrf_probe()</p> <p>In hackrf driver, the following race condition occurs: ``` CPU0 CPU1 hackrf_probe() kzalloc(); // alloc hackrf_dev .... v4l2_device_register(); .... fd = sys_open(&#34;/path/to/dev&#34;); // open hackrf fd .... v4l2_device_unregister(); .... kfree(); // free hackrf_dev .... sys_ioctl(fd, ...); v4l2_ioctl(); video_is_registered() // UAF!! .... sys_close(fd); v4l2_release() // UAF!! hackrf_video_release() kfree(); // DFB!! ```</p> <p>When a V4L2 or video device is unregistered, the device node is removed so new open() calls are blocked.</p> <p>However, file descriptors that are already open-and any in-flight I/O-do not terminate immediately; they remain valid until the last reference is dropped and the driver&#39;s release() is invoked.</p> <p>Therefore, freeing device memory on the error path after hackrf_probe() has registered dev it will lead to a race to use-after-free vuln, since those already-open handles haven&#39;t been released yet.</p> <p>And since release() free memory too, race to use-after-free and double-free vuln occur.</p> <p>To prevent this, if device is registered from probe(), it should be modified to free memory only through release() rather than calling kfree() directly.</p> https://vulnerability.circl.lu/vuln/cve-2026-31576