lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Mon, 20 Aug 2018 23:46:52 -0700 From: Srikar Dronamraju <srikar@...ux.vnet.ibm.com> To: Dmitry Torokhov <dmitry.torokhov@...il.com> Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>, lkml <linux-kernel@...r.kernel.org>, Andrew Morton <akpm@...ux-foundation.org>, Linus Torvalds <torvalds@...ux-foundation.org>, "David S. Miller" <davem@...emloft.net> Subject: Re: [PATCH] kobject: Access kobject name with caution if state is not initialized * Dmitry Torokhov <dmitry.torokhov@...il.com> [2018-08-20 12:33:50]: > On Mon, Aug 20, 2018 at 12:22 PM Greg Kroah-Hartman > <gregkh@...uxfoundation.org> wrote: > > > > On Mon, Aug 20, 2018 at 10:39:47PM +0530, Srikar Dronamraju wrote: > > Lots of stupid modules can do dumb things. Just don't do that. The > > kernel is not built to keep you from doing stupid things in kernel code > > :) > > > > So I fail to see why this patch is needed. What in-kernel code path is > > trying to print a kobject's name before it is initialized? Why not fix > > that obvious bug instead of forcing the kernel core to protect from > > stupid code? > > Kay decided to add some guards in: > > commit 0f4dafc0563c6c49e17fe14b3f5f356e4c4b8806 > Author: Kay Sievers <kay.sievers@...y.org> > Date: Wed Dec 19 01:40:42 2007 +0100 > > Kobject: auto-cleanup on final unref > ... > > + if (!kobj->state_initialized) { > + printk(KERN_ERR "kobject '%s' (%p): tried to add an " > + "uninitialized object, something is seriously wrong.\n", > + kobject_name(kobj), kobj); > + dump_stack(); > + return -EINVAL; > > Given that we have dump_stack() we can probably simply drop > kobject_name(kobj) instead of building even more elaborate checks. Or > just drop the whole check. Adding kobjects is somewhat uncommon > operation, plus "gabage in, garbage out". > Dropping the kobject_name(kobj) should also be okay.
Powered by blists - more mailing lists