[PATCH] kobject: fix NULL pointer derefernce in kobj_child_ns_ops

[PATCH] kobject: fix NULL pointer derefernce in kobj_child_ns_ops

[Pankaj Dubey]

We will hit NULL pointer dereference if we call
platform_device_register_simple or platform_device_add at very early
stage. I have observed following crash when called platform_device_add
from "init_irq" hook of machine_desc. This patch fixes this issue and
let system handle this case gracefully instead of kernel panic.

[0.000000] Unable to handle kernel NULL pointer dereference at
virtual address 0000000c
[0.000000] pgd = c0004000
[0.000000] [0000000c] *pgd=00000000
[0.000000] Internal error: Oops: 5 [#1] PREEMPT ARM
[0.000000] Modules linked in:
[0.000000] CPU: 0 PID: 0 Comm: swapper Tainted: G        W
3.17.0-rc6-00198-ga1603f1-dirty #319
[0.000000] task: c05b23f0 ti: c05a8000 task.ti: c05a8000
[0.000000] PC is at kobject_namespace+0x18/0x58
[0.000000] LR is at kobject_add_internal+0x90/0x2ec
[snip]
[0.000000] [<c01b1df0>] (kobject_namespace) from [<c01b2338>]
(kobject_add_internal+0x90/0x2ec)
[0.000000] [<c01b2338>] (kobject_add_internal) from [<c01b2728>]
(kobject_add+0x4c/0x98)
[0.000000] [<c01b2728>] (kobject_add) from [<c0226274>]
(device_add+0xe8/0x51c)
[0.000000] [<c0226274>] (device_add) from [<c0229c70>]
(platform_device_add+0xb4/0x214)
[0.000000] [<c0229c70>] (platform_device_add) from [<c022a338>]
(platform_device_register_full+0xb8/0xdc)
[0.000000] [<c022a338>] (platform_device_register_full) from
[<c0570214>] (exynos_init_irq+0x90/0x9c)
[0.000000] [<c0570214>] (exynos_init_irq) from [<c056c18c>]
(init_IRQ+0x2c/0x78)
[0.000000] [<c056c18c>] (init_IRQ) from [<c0569a54>]
(start_kernel+0x22c/0x378)
[0.000000] [<c0569a54>] (start_kernel) from [<40008070>]
(0x40008070)
[0.000000] Code: e590000c e3500000 0a00000e e5903014 (e593300c)

Signed-off-by: Pankaj Dubey <pankaj.dubey@samsung.com>
---
 lib/kobject.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/kobject.c b/lib/kobject.c
index 58751bb..03d4ab3 100644
--- a/lib/kobject.c
+++ b/lib/kobject.c
@@ -976,7 +976,7 @@ const struct kobj_ns_type_operations *kobj_child_ns_ops(struct kobject *parent)
 {
 	const struct kobj_ns_type_operations *ops = NULL;
 
-	if (parent && parent->ktype->child_ns_type)
+	if (parent && parent->ktype && parent->ktype->child_ns_type)
 		ops = parent->ktype->child_ns_type(parent);
 
 	return ops;
-- 
1.7.9.5

Re: [PATCH] kobject: fix NULL pointer derefernce in kobj_child_ns_ops

[Greg KH]

On Wed, Sep 24, 2014 at 04:25:54PM +0530, Pankaj Dubey wrote:
> We will hit NULL pointer dereference if we call
> platform_device_register_simple or platform_device_add at very early
> stage. I have observed following crash when called platform_device_add
> from "init_irq" hook of machine_desc. This patch fixes this issue and
> let system handle this case gracefully instead of kernel panic.

Is there any in-tree code that needs this "fix"?  Or can it wait for
3.18?

thanks,

greg k-h

RE: [PATCH] kobject: fix NULL pointer derefernce in kobj_child_ns_ops

[Pankaj Dubey]

Hi Greg,

On Thursday, September 25, 2014 4:15 PM, Greg KH wrote,
> To: Pankaj Dubey
> Cc: linux-kernel@vger.kernel.org; naushad@samsung.com
> Subject: Re: [PATCH] kobject: fix NULL pointer derefernce in
kobj_child_ns_ops
> 
> On Wed, Sep 24, 2014 at 04:25:54PM +0530, Pankaj Dubey wrote:
> > We will hit NULL pointer dereference if we call
> > platform_device_register_simple or platform_device_add at very early
> > stage. I have observed following crash when called platform_device_add
> > from "init_irq" hook of machine_desc. This patch fixes this issue and
> > let system handle this case gracefully instead of kernel panic.
> 
> Is there any in-tree code that needs this "fix"?  Or can it wait for 3.18?
> 

Even though I am not completely sure, at least I could not see any in-tree
code
which may need this fix.
I posted this fix, because while working on one of syscon patch [1] I wanted
to call
"platform_device_add" in one of APIs which may get called during very early
stage
of system boot, and during that time it will lead to kernel panic.

But mine syscon related patch is still under review, so I think this patch
can wait
for 3.18.

[1]: https://lkml.org/lkml/2014/9/22/12

Thanks,
Pankaj Dubey


> thanks,
> 
> greg k-h