user/sven/linux.git/net, branch v3.12.59

netfilter: x_tables: make sure e->next_offset covers remaining blob size

2016-04-23T07:24:40Z

commit 6e94e0cfb0887e4013b3b930fa6ab1fe6bb6ba91 upstream. Otherwise this function may read data beyond the ruleset blob. Signed-off-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso Cc: Michal Kubecek Signed-off-by: Jiri Slaby

netfilter: x_tables: fix unconditional helper

2016-04-21T11:11:55Z

commit 54d83fc74aa9ec72794373cb47432c5f7fb1a309 upstream. Ben Hawkes says: In the mark_source_chains function (net/ipv4/netfilter/ip_tables.c) it is possible for a user-supplied ipt_entry structure to have a large next_offset field. This field is not bounds checked prior to writing a counter value at the supplied offset. Problem is that mark_source_chains should not have been called -- the rule doesn't have a next entry, so its supposed to return an absolute verdict of either ACCEPT or DROP. However, the function conditional() doesn't work as the name implies. It only checks that the rule is using wildcard address matching. However, an unconditional rule must also not be using any matches (no -m args). The underflow validator only checked the addresses, therefore passing the 'unconditional absolute verdict' test, while mark_source_chains also tested for presence of matches, and thus proceeeded to the next (not-existent) rule. Unify this so that all the callers have same idea of 'unconditional rule'. Reported-by: Ben Hawkes Signed-off-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso Signed-off-by: Jiri Slaby

netfilter: x_tables: validate e->target_offset early

2016-04-21T11:11:55Z

commit bdf533de6968e9686df777dc178486f600c6e617 upstream. We should check that e->target_offset is sane before mark_source_chains gets called since it will fetch the target entry for loop detection. Signed-off-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso Acked-by: Michal Kubecek Signed-off-by: Jiri Slaby

SUNRPC: Fix large reads on NFS/RDMA

2016-04-21T11:11:54Z

commit 2b7bbc963da8d076f263574af4138b5df2e1581f upstream. After commit a11a2bf4, "SUNRPC: Optimise away unnecessary data moves in xdr_align_pages", Thu Aug 2 13:21:43 2012, READs larger than a few hundred bytes via NFS/RDMA no longer work. This commit exposed a long-standing bug in rpcrdma_inline_fixup(). I reproduce this with an rsize=4096 mount using the cthon04 basic tests. Test 5 fails with an EIO error. For my reproducer, kernel log shows: NFS: server cheating in read reply: count 4096 > recvd 0 rpcrdma_inline_fixup() is zeroing the xdr_stream::page_len field, and xdr_align_pages() is now returning that value to the READ XDR decoder function. That field is set up by xdr_inline_pages() by the READ XDR encoder function. As far as I can tell, it is supposed to be left alone after that, as it describes the dimensions of the reply xdr_stream, not the contents of that stream. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=68391 Signed-off-by: Chuck Lever Signed-off-by: Trond Myklebust Signed-off-by: Jiri Slaby

mac80211: fix unnecessary frame drops in mesh fwding

2016-04-20T06:46:47Z

commit cf44012810ccdd8fd947518e965cb04b7b8498be upstream. The ieee80211_queue_stopped() expects hw queue number but it was given raw WMM AC number instead. This could cause frame drops and problems with traffic in some cases - most notably if driver doesn't map AC numbers to queue numbers 1:1 and uses ieee80211_stop_queues() and ieee80211_wake_queue() only without ever calling ieee80211_wake_queues(). On ath10k it was possible to hit this problem in the following case: 1. wlan0 uses queue 0 (ath10k maps queues per vif) 2. offchannel uses queue 15 3. queues 1-14 are unused 4. ieee80211_stop_queues() 5. ieee80211_wake_queue(q=0) 6. ieee80211_wake_queue(q=15) (other queues are not woken up because both driver and mac80211 know other queues are unused) 7. ieee80211_rx_h_mesh_fwding() 8. ieee80211_select_queue_80211() returns 2 9. ieee80211_queue_stopped(q=2) returns true 10. frame is dropped (oops!) Fixes: d3c1597b8d1b ("mac80211: fix forwarded mesh frame queue mapping") Signed-off-by: Michal Kazior Signed-off-by: Johannes Berg Signed-off-by: Jiri Slaby

ipv6: Count in extension headers in skb->network_header

2016-04-19T14:46:41Z

[ Upstream commit 3ba3458fb9c050718b95275a3310b74415e767e2 ] When sending a UDPv6 message longer than MTU, account for the length of fragmentable IPv6 extension headers in skb->network_header offset. Same as we do in alloc_new_skb path in __ip6_append_data(). This ensures that later on __ip6_make_skb() will make space in headroom for fragmentable extension headers: /* move skb->data to ip header from ext header */ if (skb->data < skb_network_header(skb)) __skb_pull(skb, skb_network_offset(skb)); Prevents a splat due to skb_under_panic: skbuff: skb_under_panic: text:ffffffff8143397b len:2126 put:14 \ head:ffff880005bacf50 data:ffff880005bacf4a tail:0x48 end:0xc0 dev:lo ------------[ cut here ]------------ kernel BUG at net/core/skbuff.c:104! invalid opcode: 0000 [#1] KASAN CPU: 0 PID: 160 Comm: reproducer Not tainted 4.6.0-rc2 #65 [...] Call Trace: [] skb_push+0x79/0x80 [] eth_header+0x2b/0x100 [] neigh_resolve_output+0x210/0x310 [] ip6_finish_output2+0x4a7/0x7c0 [] ip6_output+0x16a/0x280 [] ip6_local_out+0xb1/0xf0 [] ip6_send_skb+0x45/0xd0 [] udp_v6_send_skb+0x246/0x5d0 [] udpv6_sendmsg+0xa6e/0x1090 [...] Reported-by: Ji Jianwen Signed-off-by: Jakub Sitnicki Acked-by: Hannes Frederic Sowa Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby

ip6_tunnel: set rtnl_link_ops before calling register_netdevice

2016-04-19T14:43:43Z

[ Upstream commit b6ee376cb0b7fb4e7e07d6cd248bd40436fb9ba6 ] When creating an ip6tnl tunnel with ip tunnel, rtnl_link_ops is not set before ip6_tnl_create2 is called. When register_netdevice is called, there is no linkinfo attribute in the NEWLINK message because of that. Setting rtnl_link_ops before calling register_netdevice fixes that. Fixes: 0b112457229d ("ip6tnl: add support of link creation via rtnl") Signed-off-by: Thadeu Lima de Souza Cascardo Acked-by: Nicolas Dichtel Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby

ipv6: l2tp: fix a potential issue in l2tp_ip6_recv

2016-04-19T14:43:43Z

[ Upstream commit be447f305494e019dfc37ea4cdf3b0e4200b4eba ] pskb_may_pull() can change skb->data, so we have to load ptr/optr at the right place. Signed-off-by: Haishuang Yan Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby

ipv4: l2tp: fix a potential issue in l2tp_ip_recv

2016-04-19T14:43:43Z

[ Upstream commit 5745b8232e942abd5e16e85fa9b27cc21324acf0 ] pskb_may_pull() can change skb->data, so we have to load ptr/optr at the right place. Signed-off-by: Haishuang Yan Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby

xfrm: Fix crash observed during device unregistration and decryption

2016-04-19T14:37:58Z

[ Upstream commit 071d36bf21bcc837be00cea55bcef8d129e7f609 ] A crash is observed when a decrypted packet is processed in receive path. get_rps_cpus() tries to dereference the skb->dev fields but it appears that the device is freed from the poison pattern. [] get_rps_cpu+0x94/0x2f0 [] netif_rx_internal+0x140/0x1cc [] netif_rx+0x74/0x94 [] xfrm_input+0x754/0x7d0 [] xfrm_input_resume+0x10/0x1c [] esp_input_done+0x20/0x30 [] process_one_work+0x244/0x3fc [] worker_thread+0x2f8/0x418 [] kthread+0xe0/0xec -013|get_rps_cpu( | dev = 0xFFFFFFC08B688000, | skb = 0xFFFFFFC0C76AAC00 -> ( | dev = 0xFFFFFFC08B688000 -> ( | name = "...................................................... | name_hlist = (next = 0xAAAAAAAAAAAAAAAA, pprev = 0xAAAAAAAAAAA Following are the sequence of events observed - - Encrypted packet in receive path from netdevice is queued - Encrypted packet queued for decryption (asynchronous) - Netdevice brought down and freed - Packet is decrypted and returned through callback in esp_input_done - Packet is queued again for process in network stack using netif_rx Since the device appears to have been freed, the dereference of skb->dev in get_rps_cpus() leads to an unhandled page fault exception. Fix this by holding on to device reference when queueing packets asynchronously and releasing the reference on call back return. v2: Make the change generic to xfrm as mentioned by Steffen and update the title to xfrm Suggested-by: Herbert Xu Signed-off-by: Jerome Stanislaus Signed-off-by: Subash Abhinov Kasiviswanathan Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby