In the Linux kernel, the following vulnerability has been resolved:module: ensure that kobject_put() is safe for module type kobjectsIn lookup_or_create_module_kobject() , an internal kobject is createdusing module_ktype . So call to kobject_put() on error handlingpath causes an attempt to use an uninitialized completion pointer in module_kobject_release() . In this scenario, we just want to releasekobject without an extra synchronization required for a regular moduleunloading process, so adding an extra check whether complete() isactually required makes kobject_put() safe.
In the Linux kernel, the following vulnerability has been resolved:module: ensure that kobject_put() is safe for module type kobjectsIn lookup_or_create_module_kobject() , an internal kobject is createdusing module_ktype . So call to kobject_put() on error handlingpath causes an attempt to use an uninitialized completion pointer in module_kobject_release() . In this scenario, we just want to releasekobject without an extra synchronization required for a regular moduleunloading process, so adding an extra check whether complete() isactually required makes kobject_put() safe.
In the Linux kernel, the following vulnerability has been resolved:module: ensure that kobject_put() is safe for module type kobjectsIn lookup_or_create_module_kobject() , an internal kobject is createdusing module_ktype . So call to kobject_put() on error handlingpath causes an attempt to use an uninitialized completion pointer in module_kobject_release() . In this scenario, we just want to releasekobject without an extra synchronization required for a regular moduleunloading process, so adding an extra check whether complete() isactually required makes kobject_put() safe.
In the Linux kernel, the following vulnerability has been resolved:module: ensure that kobject_put() is safe for module type kobjectsIn lookup_or_create_module_kobject() , an internal kobject is createdusing module_ktype . So call to kobject_put() on error handlingpath causes an attempt to use an uninitialized completion pointer in module_kobject_release() . In this scenario, we just want to releasekobject without an extra synchronization required for a regular moduleunloading process, so adding an extra check whether complete() isactually required makes kobject_put() safe.
In the Linux kernel, the following vulnerability has been resolved:module: ensure that kobject_put() is safe for module type kobjectsIn lookup_or_create_module_kobject() , an internal kobject is createdusing module_ktype . So call to kobject_put() on error handlingpath causes an attempt to use an uninitialized completion pointer in module_kobject_release() . In this scenario, we just want to releasekobject without an extra synchronization required for a regular moduleunloading process, so adding an extra check whether complete() isactually required makes kobject_put() safe.
In the Linux kernel, the following vulnerability has been resolved:module: ensure that kobject_put() is safe for module type kobjectsIn lookup_or_create_module_kobject() , an internal kobject is createdusing module_ktype . So call to kobject_put() on error handlingpath causes an attempt to use an uninitialized completion pointer in module_kobject_release() . In this scenario, we just want to releasekobject without an extra synchronization required for a regular moduleunloading process, so adding an extra check whether complete() isactually required makes kobject_put() safe.
In the Linux kernel, the following vulnerability has been resolved:module: ensure that kobject_put() is safe for module type kobjectsIn 'lookup_or_create_module_kobject()', an internal kobject is createdusing 'module_ktype'. So call to 'kobject_put()' on error handlingpath causes an attempt to use an uninitialized completion pointer in'module_kobject_release()'. In this scenario, we just want to releasekobject without an extra synchronization required for a regular moduleunloading process, so adding an extra check whether 'complete()' isactually required makes 'kobject_put()' safe.The Linux kernel CVE team has assigned CVE-2025-37995 to this issue.
