https://vulnerability.circl.lu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Mon, 05 Oct 2026 06:42:25 +0000 https://vulnerability.circl.lu/vuln/cve-2025-37995 <p><strong>Affected:</strong> Linux</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>module: ensure that kobject_put() is safe for module type kobjects</p> <p>In &#39;lookup_or_create_module_kobject()&#39;, an internal kobject is created using &#39;module_ktype&#39;. So call to &#39;kobject_put()&#39; on error handling path causes an attempt to use an uninitialized completion pointer in &#39;module_kobject_release()&#39;. In this scenario, we just want to release kobject without an extra synchronization required for a regular module unloading process, so adding an extra check whether &#39;complete()&#39; is actually required makes &#39;kobject_put()&#39; safe.</p> <p><strong>Affected:</strong> Linux</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>module: ensure that kobject_put() is safe for module type kobjects</p> <p>In &#39;lookup_or_create_module_kobject()&#39;, an internal kobject is created using &#39;module_ktype&#39;. So call to &#39;kobject_put()&#39; on error handling path causes an attempt to use an uninitialized completion pointer in &#39;module_kobject_release()&#39;. In this scenario, we just want to release kobject without an extra synchronization required for a regular module unloading process, so adding an extra check whether &#39;complete()&#39; is actually required makes &#39;kobject_put()&#39; safe.</p> https://vulnerability.circl.lu/vuln/cve-2025-37995