[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <1335002414.2188.27.camel@yan>
Date: Sat, 21 Apr 2012 17:58:31 +0800
From: yan <clouds.yan@...il.com>
To: greg <gregkh@...uxfoundation.org>
Cc: kernel <linux-kernel@...r.kernel.org>,
message <message.get@...il.com>
Subject: [PATCH 3/4][Trivial] 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_ops
In the end, it will call ->ktype->child_ns_type directly and we have
an oops.
Check ktype before really add a kobject.
Signed-off-by: Yan Hong <clouds.yan@...il.com>
---
lib/kobject.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/lib/kobject.c b/lib/kobject.c
index 85d5e9b..3ba6216 100644
--- a/lib/kobject.c
+++ b/lib/kobject.c
@@ -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);
--
1.7.5.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists