aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/xen
diff options
context:
space:
mode:
authorPavel Emelyanov <xemul@openvz.org>2007-12-05 02:45:24 -0500
committerLinus Torvalds <torvalds@woody.linux-foundation.org>2007-12-05 12:21:20 -0500
commitf1dad166e88a5ddca0acf8f11dea0e2bd92d8bf3 (patch)
treee907d1de7ee3bad49b101336a0b1640e8d05bd51 /drivers/xen
parent092e1fdaf35126475aef0dc70f4a2ce4f2f43052 (diff)
Avoid potential NULL dereference in unregister_sysctl_table
register_sysctl_table() can return NULL sometimes, e.g. when kmalloc() returns NULL or when sysctl check fails. I've also noticed, that many (most?) code in the kernel doesn't check for the return value from register_sysctl_table() and later simply calls the unregister_sysctl_table() with potentially NULL argument. This is unlikely on a common kernel configuration, but in case we're dealing with modules and/or fault-injection support, there's a slight possibility of an OOPS. Changing all the users to check for return code from the registering does not look like a good solution - there are too many code doing this and failure in sysctl tables registration is not a good reason to abort module loading (in most of the cases). So I think, that we can just have this check in unregister_sysctl_table just to avoid accidental OOPS-es (actually, the unregister_sysctl_table() did exactly this, before the start_unregistering() appeared). Signed-off-by: Pavel Emelyanov <xemul@openvz.org> Cc: "Eric W. Biederman" <ebiederm@xmission.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Diffstat (limited to 'drivers/xen')
0 files changed, 0 insertions, 0 deletions