lib/kobject.c : Check ktype in kobject_add_internal
Subsystems (2)
PATCH 3/4 lib/kobject.c : Check ktype in kobject_add_internal
If someone calls kobject_init with null kobj_type, kobject_init can detect it. But it does not have a return value, it just dumps stack. In this case, a kobject_add after that will result in:
-->kobject_add_varg
-->kobject_add_internal
-->create_dir
-->sysfs_create_dir
-->sysfs_read_ns_type
-->kobj_child_ns_opsIn the end, it will call ->ktype->child_ns_type directly and we have an oops.
Check ktype before really add a kobject.
--- lib/kobject.c | 3 +++ 1 files changed, 3 insertions(+), 0 deletions(-)
lib/kobject.c +3 -0
@@ -164,6 +164,9 @@ static int kobject_add_internal(struct kobject *kobj)if (!kobj)return -ENOENT ; +if (!kobj->ktype) +return -EINVAL ; +if (!kobj->name || !kobj->name[0 ]) {WARN (1 ,"kobject: (%p): attempted to be registered with empty " "name!\n" , kobj);
Signature · 1 line
1.7.5.1
greg
maintainerQuoted 9 lines · yan
If someone calls
kobject_initwith nullkobj_type,kobject_initcan detect it. But it does not have a return value, it just dumps stack. In this case, akobject_addafter that will result in:-->kobject_add_varg -->kobject_add_internal -->create_dir -->sysfs_create_dir -->sysfs_read_ns_type -->kobj_child_ns_ops
Quoted 4 lines
In the end, it will call ->ktype->child_ns_type directly and we have an oops.
Check ktype before really add a kobject.
But how can we add a kobject without a valid ktype?
At the most, I'd prefer to warn about this, much like we warn about not having a name, and not just returning an error without a hint as to what went wrong.
greg k-h