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" <[email protected]>
Signed-off-by: Akinobu Mita <[email protected]>
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 <[email protected]> wrote:
> 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.
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 <[email protected]> wrote:
>
>>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 <[email protected]>
Date: Sun, 13 Aug 2006 20:49:06 +0200
> Andrew Morton wrote:
> > On Sun, 13 Aug 2006 13:52:58 +0200
> > Patrick McHardy <[email protected]> wrote:
> >
> >>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.