[PATCH] fix use after free in netlink_kernel_create()

This patch invalidates nl_table by setting NULL when netlink
initialization failed. Otherwise netlink_kernel_create() would
access nl_table which has already been freed.

CC: "David S. Miller" <davem@davemloft.net>
Signed-off-by: Akinobu Mita <redacted>

 net/netlink/af_netlink.c |   11 ++++++-----
 1 file changed, 6 insertions(+), 5 deletions(-)

Index: work-failmalloc/net/netlink/af_netlink.c
===================================================================

--- work-failmalloc.orig/net/netlink/af_netlink.c
+++ work-failmalloc/net/netlink/af_netlink.c

@@ -1745,11 +1745,8 @@ static int __init netlink_proto_init(voi
 		netlink_skb_parms_too_large();
 
 	nl_table = kcalloc(MAX_LINKS, sizeof(*nl_table), GFP_KERNEL);
-	if (!nl_table) {
-enomem:
-		printk(KERN_CRIT "netlink_init: Cannot allocate nl_table\n");
-		return -ENOMEM;
-	}
+	if (!nl_table)
+		goto enomem;
 
 	if (num_physpages >= (128 * 1024))
 		max = num_physpages >> (21 - PAGE_SHIFT);

@@ -1769,6 +1766,7 @@ enomem:
 				nl_pid_hash_free(nl_table[i].hash.table,
 						 1 * sizeof(*hash->table));
 			kfree(nl_table);
+			nl_table = NULL;
 			goto enomem;
 		}
 		memset(hash->table, 0, 1 * sizeof(*hash->table));

@@ -1786,6 +1784,9 @@ enomem:
 	rtnetlink_init();
 out:
 	return err;
+enomem:
+	printk(KERN_CRIT "netlink_init: Cannot allocate nl_table\n");
+	return -ENOMEM;
 }
 
 core_initcall(netlink_proto_init);

Akinobu Mita wrote:

This patch invalidates nl_table by setting NULL when netlink
initialization failed. Otherwise netlink_kernel_create() would
access nl_table which has already been freed.

Quite a few users of netlink_kernel_create will panic when creating
the socket fails (rtnetlink for example, which is always present),
so you might as well call panic here directly.

On Sun, 13 Aug 2006 13:52:58 +0200
Patrick McHardy [off-list ref] wrote:

Akinobu Mita wrote:

quoted

This patch invalidates nl_table by setting NULL when netlink
initialization failed. Otherwise netlink_kernel_create() would
access nl_table which has already been freed.

Quite a few users of netlink_kernel_create will panic when creating
the socket fails (rtnetlink for example, which is always present),
so you might as well call panic here directly.

That's a bit lame.  Panicing at do_initcalls() time is OK (something is
seriously screwed anyway) but we usually try to handle the ENOMEM nicely if
it happens at modprobe-time.

(It's all pretty theoretical anyway - reasonable-sized GFP_KERNEL
allocations don't fail).

Andrew Morton wrote:

On Sun, 13 Aug 2006 13:52:58 +0200
Patrick McHardy [off-list ref] wrote:

quoted

Quite a few users of netlink_kernel_create will panic when creating
the socket fails (rtnetlink for example, which is always present),
so you might as well call panic here directly.

That's a bit lame.  Panicing at do_initcalls() time is OK (something is
seriously screwed anyway) but we usually try to handle the ENOMEM nicely if
it happens at modprobe-time.

The users I looked at can't be built as modules (rtnetlink, genetlink,
audit subsystem), I'm not aware of any modules panicing on
netlink_kernel_create failure. But all of netlink, genetlink and
rtnetlink are always built-in when CONFIG_NET=y, so we might as well
panic here.

From: Patrick McHardy <redacted>
Date: Sun, 13 Aug 2006 20:49:06 +0200

Andrew Morton wrote:

quoted

On Sun, 13 Aug 2006 13:52:58 +0200
Patrick McHardy [off-list ref] wrote:

quoted

Quite a few users of netlink_kernel_create will panic when creating
the socket fails (rtnetlink for example, which is always present),
so you might as well call panic here directly.

That's a bit lame.  Panicing at do_initcalls() time is OK (something is
seriously screwed anyway) but we usually try to handle the ENOMEM nicely if
it happens at modprobe-time.

The users I looked at can't be built as modules (rtnetlink, genetlink,
audit subsystem), I'm not aware of any modules panicing on
netlink_kernel_create failure. But all of netlink, genetlink and
rtnetlink are always built-in when CONFIG_NET=y, so we might as well
panic here.

Agreed.

netlink_proto_init() is a core_initcall(), we are pretty much in
an irrecoverable bind if that thing fails, so panic() is appropriate
here.