CVE-2026-31576

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: hackrf: fix to not free memory after the device is registered in hackrf_probe()<br /> <br /> In hackrf driver, the following race condition occurs:<br /> ```<br /> CPU0 CPU1<br /> hackrf_probe()<br /> kzalloc(); // alloc hackrf_dev<br /> ....<br /> v4l2_device_register();<br /> ....<br /> fd = sys_open("/path/to/dev"); // open hackrf fd<br /> ....<br /> v4l2_device_unregister();<br /> ....<br /> kfree(); // free hackrf_dev<br /> ....<br /> sys_ioctl(fd, ...);<br /> v4l2_ioctl();<br /> video_is_registered() // UAF!!<br /> ....<br /> sys_close(fd);<br /> v4l2_release() // UAF!!<br /> hackrf_video_release()<br /> kfree(); // DFB!!<br /> ```<br /> <br /> When a V4L2 or video device is unregistered, the device node is removed so<br /> new open() calls are blocked.<br /> <br /> However, file descriptors that are already open-and any in-flight I/O-do<br /> not terminate immediately; they remain valid until the last reference is<br /> dropped and the driver&amp;#39;s release() is invoked.<br /> <br /> Therefore, freeing device memory on the error path after hackrf_probe()<br /> has registered dev it will lead to a race to use-after-free vuln, since<br /> those already-open handles haven&amp;#39;t been released yet.<br /> <br /> And since release() free memory too, race to use-after-free and<br /> double-free vuln occur.<br /> <br /> To prevent this, if device is registered from probe(), it should be<br /> modified to free memory only through release() rather than calling<br /> kfree() directly.