Pablo Neira 3a36515f72 netlink: fix splat in skb_clone with large messages ... Since (c05cdb1 netlink: allow large data transfers from user-space), netlink splats if it invokes skb_clone on large netlink skbs since: * skb_shared_info was not correctly initialized. * skb->destructor is not set in the cloned skb. This was spotted by trinity: [ 894.990671] BUG: unable to handle kernel paging request at ffffc9000047b001 [ 894.991034] IP: [<ffffffff81a212c4>] skb_clone+0x24/0xc0 [...] [ 894.991034] Call Trace: [ 894.991034] [<ffffffff81ad299a>] nl_fib_input+0x6a/0x240 [ 894.991034] [<ffffffff81c3b7e6>] ? _raw_read_unlock+0x26/0x40 [ 894.991034] [<ffffffff81a5f189>] netlink_unicast+0x169/0x1e0 [ 894.991034] [<ffffffff81a601e1>] netlink_sendmsg+0x251/0x3d0 Fix it by: 1) introducing a new netlink_skb_clone function that is used in nl_fib_input, that sets our special skb->destructor in the cloned skb. Moreover, handle the release of the large cloned skb head area in the destructor path. 2) not allowing large skbuffs in the netlink broadcast path. I cannot find any reasonable use of the large data transfer using netlink in that path, moreover this helps to skip extra skb_clone handling. I found two more netlink clients that are cloning the skbs, but they are not in the sendmsg path. Therefore, the sole client cloning that I found seems to be the fib frontend. Thanks to Eric Dumazet for helping to address this issue. Reported-by: Fengguang Wu <fengguang.wu@intel.com> Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org> Signed-off-by: David S. Miller <davem@davemloft.net>		2013-06-27 22:44:16 -07:00
..
Kconfig	netlink: kconfig: move mmap i/o into netlink kconfig	2013-05-01 15:02:42 -04:00
Makefile	netlink: Diag core and basic socket info dumping (v2)	2013-03-21 12:38:03 -04:00
af_netlink.c	netlink: fix splat in skb_clone with large messages	2013-06-27 22:44:16 -07:00
af_netlink.h	netlink: Add compare function for netlink_table	2013-06-11 02:39:42 -07:00
diag.c	netlink: Fix build with mmap disabled.	2013-04-23 15:39:03 -04:00
genetlink.c	genetlink: fix possible memory leak in genl_family_rcv_msg()	2013-04-26 23:25:39 -04:00