https://db.gcve.eu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Tue, 29 Sep 2026 23:03:15 +0000 https://db.gcve.eu/vuln/cve-2023-53515 <p><strong>Affected:</strong> Linux</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>virtio-mmio: don&#39;t break lifecycle of vm_dev</p> <p>vm_dev has a separate lifecycle because it has a &#39;struct device&#39; embedded. Thus, having a release callback for it is correct.</p> <p>Allocating the vm_dev struct with devres totally breaks this protection, though. Instead of waiting for the vm_dev release callback, the memory is freed when the platform_device is removed. Resulting in a use-after-free when finally the callback is to be called.</p> <p>To easily see the problem, compile the kernel with CONFIG_DEBUG_KOBJECT_RELEASE and unbind with sysfs.</p> <p>The fix is easy, don&#39;t use devres in this case.</p> <p>Found during my research about object lifetime problems.</p> <p><strong>Affected:</strong> Linux</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>virtio-mmio: don&#39;t break lifecycle of vm_dev</p> <p>vm_dev has a separate lifecycle because it has a &#39;struct device&#39; embedded. Thus, having a release callback for it is correct.</p> <p>Allocating the vm_dev struct with devres totally breaks this protection, though. Instead of waiting for the vm_dev release callback, the memory is freed when the platform_device is removed. Resulting in a use-after-free when finally the callback is to be called.</p> <p>To easily see the problem, compile the kernel with CONFIG_DEBUG_KOBJECT_RELEASE and unbind with sysfs.</p> <p>The fix is easy, don&#39;t use devres in this case.</p> <p>Found during my research about object lifetime problems.</p> https://db.gcve.eu/vuln/cve-2023-53515