linux/net, branch v3.14.6

libceph: fix corruption when using page_count 0 page in rbd

2014-06-07T17:28:28Z

commit 178eda29ca721842f2146378e73d43e0044c4166 upstream. It has been reported that using ZFSonLinux on rbd will result in memory corruption. The bug report can be found here: https://github.com/zfsonlinux/spl/issues/241 http://tracker.ceph.com/issues/7790 The reason is that ZFS will send pages with page_count 0 into rbd, which in turns send them to tcp_sendpage. However, tcp_sendpage cannot deal with page_count 0, as it will do get_page and put_page, and erroneously free the page. This type of issue has been noted before, and handled in iscsi, drbd, etc. So, rbd should also handle this. This fix address this issue by fall back to slower sendmsg when page_count 0 detected. Cc: Sage Weil Cc: Yehuda Sadeh Signed-off-by: Chunwei Chen Reviewed-by: Ilya Dryomov Signed-off-by: Greg Kroah-Hartman

Bluetooth: Fix redundant encryption request for reauthentication

2014-06-07T17:28:16Z

commit 09da1f3463eb81d59685df723b1c5950b7570340 upstream. When we're performing reauthentication (in order to elevate the security level from an unauthenticated key to an authenticated one) we do not need to issue any encryption command once authentication completes. Since the trigger for the encryption HCI command is the ENCRYPT_PEND flag this flag should not be set in this scenario. Instead, the REAUTH_PEND flag takes care of all necessary steps for reauthentication. Signed-off-by: Johan Hedberg Signed-off-by: Marcel Holtmann Signed-off-by: Greg Kroah-Hartman

Bluetooth: Fix triggering BR/EDR L2CAP Connect too early

2014-06-07T17:28:16Z

commit 9eb1fbfa0a737fd4d3a6d12d71c5ea9af622b887 upstream. Commit 1c2e004183178 introduced an event handler for the encryption key refresh complete event with the intent of fixing some LE/SMP cases. However, this event is shared with BR/EDR and there we actually want to act only on the auth_complete event (which comes after the key refresh). If we do not do this we may trigger an L2CAP Connect Request too early and cause the remote side to return a security block error. Signed-off-by: Johan Hedberg Signed-off-by: Marcel Holtmann Signed-off-by: Greg Kroah-Hartman

mac80211: fix on-channel remain-on-channel

2014-06-07T17:28:10Z

commit b4b177a5556a686909e643f1e9b6434c10de079f upstream. Jouni reported that if a remain-on-channel was active on the same channel as the current operating channel, then the ROC would start, but any frames transmitted using mgmt-tx on the same channel would get delayed until after the ROC. The reason for this is that the ROC starts, but doesn't have any handling for "remain on the same channel", so it stops the interface queues. The later mgmt-tx then puts the frame on the interface queues (since it's on the current operating channel) and thus they get delayed until after the ROC. To fix this, add some logic to handle remaining on the same channel specially and not stop the queues etc. in this case. This not only fixes the bug but also improves behaviour in this case as data frames etc. can continue to flow. Reported-by: Jouni Malinen Tested-by: Jouni Malinen Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman

mac80211: fix suspend vs. association race

2014-06-07T17:28:10Z

commit c52666aef9f2dff39276eb53f15d99e2e229870f upstream. If the association is in progress while we suspend, the stack will be in a messed up state. Clean it before we suspend. This patch completes Johannes's patch: 1a1cb744de160ee70086a77afff605bbc275d291 Author: Johannes Berg mac80211: fix suspend vs. authentication race Fixes: 12e7f517029d ("mac80211: cleanup generic suspend/resume procedures") Signed-off-by: Emmanuel Grumbach Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman

mac80211: fix nested rtnl locking on ieee80211_reconfig

2014-06-07T17:28:10Z

commit e669ba2d06c6195662601956454ac959892f0762 upstream. ieee80211_reconfig already holds rtnl, so calling cfg80211_sched_scan_stopped results in deadlock. Use the rtnl-version of this function instead. Fixes: d43c6b6 ("mac80211: reschedule sched scan after HW restart") Signed-off-by: Eliad Peller Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman

cfg80211: add cfg80211_sched_scan_stopped_rtnl

2014-06-07T17:28:10Z

commit 792e6aa7a15ea0fb16f8687e93caede1ea9118c7 upstream. Add locked-version for cfg80211_sched_scan_stopped. This is used for some users that might want to call it when rtnl is already locked. Fixes: d43c6b6 ("mac80211: reschedule sched scan after HW restart") Signed-off-by: Eliad Peller Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman

cfg80211: free sme on connection failures

2014-06-07T17:28:10Z

commit c1fbb258846dfc425507a093922d2d001e54c3ea upstream. cfg80211 is notified about connection failures by __cfg80211_connect_result() call. However, this function currently does not free cfg80211 sme. This results in hanging connection attempts in some cases e.g. when mac80211 authentication attempt is denied, we have this function call: ieee80211_rx_mgmt_auth() -> cfg80211_rx_mlme_mgmt() -> cfg80211_process_auth() -> cfg80211_sme_rx_auth() -> __cfg80211_connect_result() but cfg80211_sme_free() is never get called. Fixes: ceca7b712 ("cfg80211: separate internal SME implementation") Signed-off-by: Eliad Peller Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman

cfg80211: fix few minor issues in reg_process_hint()

2014-06-07T17:28:10Z

commit 772f0389338cfcf96da1c178046dc7e1649ab554 upstream. Fix the following issues in reg_process_hint(): 1. Add verification that wiphy is valid before processing NL80211_REGDOMAIN_SET_BY_COUNTRY_IE. 2. Free the request in case of invalid initiator. 3. Remove WARN_ON check on reg_request->alpha2 as it is not a pointer. Signed-off-by: Ilan Peer Signed-off-by: Johannes Berg Signed-off-by: Luis R. Rodriguez Signed-off-by: Greg Kroah-Hartman

net-gro: reset skb->truesize in napi_reuse_skb()

2014-05-31T20:20:39Z

[ Upstream commit e33d0ba8047b049c9262fdb1fcafb93cb52ceceb ] Recycling skb always had been very tough... This time it appears GRO layer can accumulate skb->truesize adjustments made by drivers when they attach a fragment to skb. skb_gro_receive() can only subtract from skb->truesize the used part of a fragment. I spotted this problem seeing TcpExtPruneCalled and TcpExtTCPRcvCollapsed that were unexpected with a recent kernel, where TCP receive window should be sized properly to accept traffic coming from a driver not overshooting skb->truesize. Signed-off-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman