summaryrefslogtreecommitdiffstats
path: root/net/mac80211/rx.c
Commit message (Collapse)AuthorAgeFilesLines
* mac80211: drop robust management frames from unknown TAJohannes Berg2019-07-101-0/+2
| | | | | | | | | | | | | commit 588f7d39b3592a36fb7702ae3b8bdd9be4621e2f upstream. When receiving a robust management frame, drop it if we don't have rx->sta since then we don't have a security association and thus couldn't possibly validate the frame. Cc: stable@vger.kernel.org Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* mac80211: fix miscounting of ttl-dropped framesBob Copeland2019-03-231-1/+3
| | | | | | | | | | | | | | | | | | | | [ Upstream commit a0dc02039a2ee54fb4ae400e0b755ed30e73e58c ] In ieee80211_rx_h_mesh_fwding, we increment the 'dropped_frames_ttl' counter when we decrement the ttl to zero. For unicast frames destined for other hosts, we stop processing the frame at that point. For multicast frames, we do not rebroadcast it in this case, but we do pass the frame up the stack to process it on this STA. That doesn't match the usual definition of "dropped," so don't count those as such. With this change, something like `ping6 -i0.2 ff02::1%mesh0` from a peer in a ttl=1 network no longer increments the counter rapidly. Signed-off-by: Bob Copeland <bobcopeland@fb.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
* mac80211: fix radiotap vendor presence bitmap handlingJohannes Berg2019-02-201-2/+3
| | | | | | | | | | | | | | | | | | [ Upstream commit efc38dd7d5fa5c8cdd0c917c5d00947aa0539443 ] Due to the alignment handling, it actually matters where in the code we add the 4 bytes for the presence bitmap to the length; the first field is the timestamp with 8 byte alignment so we need to add the space for the extra vendor namespace presence bitmap *before* we do any alignment for the fields. Move the presence bitmap length accounting to the right place to fix the alignment for the data properly. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
* mac80211: ignore NullFunc frames in the duplicate detectionEmmanuel Grumbach2018-12-131-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | commit 990d71846a0b7281bd933c34d734e6afc7408e7e upstream. NullFunc packets should never be duplicate just like QoS-NullFunc packets. We saw a client that enters / exits power save with NullFunc frames (and not with QoS-NullFunc) despite the fact that the association supports HT. This specific client also re-uses a non-zero sequence number for different NullFunc frames. At some point, the client had to send a retransmission of the NullFunc frame and we dropped it, leading to a misalignment in the power save state. Fix this by never consider a NullFunc frame as duplicate, just like we do for QoS NullFunc frames. This fixes https://bugzilla.kernel.org/show_bug.cgi?id=201449 CC: <stable@vger.kernel.org> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* mac80211: mesh: drop frames appearing to be from usJohannes Berg2018-03-031-0/+2
| | | | | | | | | | | | | | | [ Upstream commit 736a80bbfda709fb3631f5f62056f250a38e5804 ] If there are multiple mesh stations with the same MAC address, they will both get confused and start throwing warnings. Obviously in this case nothing can actually work anyway, so just drop frames that look like they're from ourselves early on. Reported-by: Gui Iribarren <gui@altermundi.net> Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Sasha Levin <alexander.levin@microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* mac80211: don't look at the PM bit of BAR framesEmmanuel Grumbach2017-06-261-1/+5
| | | | | | | | | | | | | commit 769dc04db3ed8484798aceb015b94deacc2ba557 upstream. When a peer sends a BAR frame with PM bit clear, we should not modify its PM state as madated by the spec in 802.11-20012 10.2.1.2. Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* mac80211: reject ToDS broadcast data framesJohannes Berg2017-04-271-0/+21
| | | | | | | | | | | | | | | | | | | | | | | | | commit 3018e947d7fd536d57e2b550c33e456d921fff8c upstream. AP/AP_VLAN modes don't accept any real 802.11 multicast data frames, but since they do need to accept broadcast management frames the same is currently permitted for data frames. This opens a security problem because such frames would be decrypted with the GTK, and could even contain unicast L3 frames. Since the spec says that ToDS frames must always have the BSSID as the RA (addr1), reject any other data frames. The problem was originally reported in "Predicting, Decrypting, and Abusing WPA2/802.11 Group Keys" at usenix https://www.usenix.org/conference/usenixsecurity16/technical-sessions/presentation/vanhoef and brought to my attention by Jouni. Reported-by: Jouni Malinen <j@w1.fi> Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> --
* mac80211: discard multicast and 4-addr A-MSDUsJohannes Berg2016-11-101-9/+15
| | | | | | | | | | | | | | | | | | | | | | commit ea720935cf6686f72def9d322298bf7e9bd53377 upstream. In mac80211, multicast A-MSDUs are accepted in many cases that they shouldn't be accepted in: * drop A-MSDUs with a multicast A1 (RA), as required by the spec in 9.11 (802.11-2012 version) * drop A-MSDUs with a 4-addr header, since the fourth address can't actually be useful for them; unless 4-address frame format is actually requested, even though the fourth address is still not useful in this case, but ignored Accepting the first case, in particular, is very problematic since it allows anyone else with possession of a GTK to send unicast frames encapsulated in a multicast A-MSDU, even when the AP has client isolation enabled. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* mac80211: fix unnecessary frame drops in mesh fwdingMichal Kazior2016-04-201-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <michal.kazior@tieto.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* mac80211: Fix Public Action frame RX in AP modeJouni Malinen2016-03-161-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | commit 1ec7bae8bec9b72e347e01330c745ab5cdd66f0e upstream. Public Action frames use special rules for how the BSSID field (Address 3) is set. A wildcard BSSID is used in cases where the transmitter and recipient are not members of the same BSS. As such, we need to accept Public Action frames with wildcard BSSID. Commit db8e17324553 ("mac80211: ignore frames between TDLS peers when operating as AP") added a rule that drops Action frames to TDLS-peers based on an Action frame having different DA (Address 1) and BSSID (Address 3) values. This is not correct since it misses the possibility of BSSID being a wildcard BSSID in which case the Address 1 would not necessarily match. Fix this by allowing mac80211 to accept wildcard BSSID in an Action frame when in AP mode. Fixes: db8e17324553 ("mac80211: ignore frames between TDLS peers when operating as AP") Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* mac80211: check PN correctly for GCMP-encrypted fragmented MPDUsJohannes Berg2016-03-161-9/+27
| | | | | | | | | | | | | | | | | | | commit 9acc54beb474c81148e2946603d141cf8716b19f upstream. Just like for CCMP we need to check that for GCMP the fragments have PNs that increment by one; the spec was updated to fix this security issue and now has the following text: The receiver shall discard MSDUs and MMPDUs whose constituent MPDU PN values are not incrementing in steps of 1. Adapt the code for CCMP to work for GCMP as well, luckily the relevant fields already alias each other so no code duplication is needed (just check the aliasing with BUILD_BUG_ON.) Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* mac80211: handle width changes from opmode notification IE in beaconEyal Shapira2015-12-151-2/+1
| | | | | | | | | | | An AP can send an operating channel width change in a beacon opmode notification IE as long as there's a change in the nss as well (See 802.11ac-2013 section 10.41). So don't limit updating to nss only from an opmode notification IE. Signed-off-by: Eyal Shapira <eyalx.shapira@intel.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: move station statistics into sub-structsJohannes Berg2015-10-211-29/+34
| | | | | | | | | | | | | | Group station statistics by where they're (mostly) updated (TX, RX and TX-status) and group them into sub-structs of the struct sta_info. Also rename the variables since the grouping now makes it obvious where they belong. This makes it easier to identify where the statistics are updated in the code, and thus easier to think about them. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: clean up ieee80211_rx_h_check_dup codeJohannes Berg2015-10-141-10/+10
| | | | | | Reduce indentation a bit to make the condition more readable. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: use DECLARE_EWMAJohannes Berg2015-08-141-2/+2
| | | | | | | | | | Instead of using the out-of-line average calculation, use the new DECLARE_EWMA() macro to declare a signal EWMA, and use that. This actually *reduces* the code size slightly (on x86-64) while also reducing the station info size by 80 bytes. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: Only accept data frames in OCB modeBertold Van den Bergh2015-08-141-1/+1
| | | | | | | | | Currently OCB mode accepts frames with bssid==broadcast and type!=beacon. Some non-data frames are sent matching this, for example probe responses. This results in unnecessary creation of STA entries. Signed-off-by: Bertold Van den Bergh <bertold.vandenbergh@esat.kuleuven.be> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: TDLS: handle chan-switch in RTNL locked workArik Nemtsov2015-07-171-3/+2
| | | | | | | | | | | | Move TDLS channel-switch Rx handling into an RTNL locked work. This is required to add proper regulatory checking to incoming channel-switch requests. Queue incoming requests in a dedicated skb queue and handle the request in a device-specific work to avoid deadlocking on interface removal. Signed-off-by: Arik Nemtsov <arikx.nemtsov@intel.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: remove IEEE80211_RX_FRAGMENTEDJohannes Berg2015-07-171-2/+0
| | | | | | | | | | | There's a long-standing TODO item to use this flag in the cooked monitor RX, but clearly it was never needed and now this hasn't been used by userspace for a long time, so no userspace changes could require it now. Remove the unused flag. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: remove key TX/RX counterJohannes Berg2015-07-171-1/+0
| | | | | | | | | | | This counter is inherently racy (since it can be incremented by RX as well as by concurrent TX) and only available in debugfs. Instead of fixing it to be per-CPU or similar, remove it for now. If needed it should be added without races and with proper nl80211, perhaps even addressing the threshold reporting TODO item that's been there since the code was originally added. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: remove zero-length A-MPDU subframe reportingJohannes Berg2015-07-171-6/+1
| | | | | | | | As there's no driver using this capability and reporting zero-length A-MPDU subframes for radiotap monitoring, remove the capability to free up two RX flags. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: don't store napi structJohannes Berg2015-07-171-8/+10
| | | | | | | | | | | | | | When introducing multiple RX queues, a single NAPI struct will not be sufficient. Instead of trying to store multiple, simply change the API to have the NAPI struct passed to the RX function. This of course means that drivers using rx_irqsafe() cannot use NAPI, but that seems a reasonable trade-off, particularly since only two of all drivers are currently using it at all. While at it, we can now remove the IEEE80211_RX_REORDER_TIMER flag again since this code path cannot have a napi struct anyway. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: move ieee80211_get_bssid into RX fileJohannes Berg2015-07-171-0/+45
| | | | | | | | | | This function is only used in the RX code, so moving it into that file gives the compiler better optimisation possibilities and also allows us to remove the check for short frames (which in the RX path cannot happen, but as a generic utility needed to be checked.) Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: remove short frame test and counterJohannes Berg2015-07-171-5/+0
| | | | | | | | | Short frames less than 16 octets are already blocked in the monitor code by the should_drop_frame() function, and cannot get into the regular RX path. Therefore, this check can never trigger and the counter invariably stays zero. Remove the useless code. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: rename 'sta_inf' variable to more common 'sta'Johannes Berg2015-07-171-6/+6
| | | | | | | | We typically use 'sta' for the station info struct, and if needed 'pubsta' for the public (driver-visible) portion thereof. Do this in the ieee80211_sta_ps_transition() function. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: convert HW flags to unsigned long bitmapJohannes Berg2015-06-101-13/+13
| | | | | | | | | | | | | | | As we're running out of hardware capability flags pretty quickly, convert them to use the regular test_bit() style unsigned long bitmaps. This introduces a number of helper functions/macros to set and to test the bits, along with new debugfs code. The occurrences of an explicit __clear_bit() are intentional, the drivers were never supposed to change their supported bits on the fly. We should investigate changing this to be a per-frame flag. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/netDavid S. Miller2015-06-011-2/+3
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Conflicts: drivers/net/phy/amd-xgbe-phy.c drivers/net/wireless/iwlwifi/Kconfig include/net/mac80211.h iwlwifi/Kconfig and mac80211.h were both trivial overlapping changes. The drivers/net/phy/amd-xgbe-phy.c file got removed in 'net-next' and the bug fix that happened on the 'net' side is already integrated into the rest of the amd-xgbe driver. Signed-off-by: David S. Miller <davem@davemloft.net>
| * mac80211: don't use napi_gro_receive() outside NAPI contextJohannes Berg2015-05-191-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | No matter how the driver manages its NAPI context, there's no way sending frames to it from a timer can be correct, since it would corrupt the internal GRO lists. To avoid that, always use the non-NAPI path when releasing frames from the timer. Cc: stable@vger.kernel.org Reported-by: Jean Trivelly <jean.trivelly@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* | mac80211: move dot11 counters under MAC80211_DEBUG_COUNTERSJohannes Berg2015-05-051-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | Since these counters can only be read through debugfs, there's very little point in maintaining them all the time. However, even just making them depend on debugfs is pointless - they're not normally used. Additionally a number of them aren't even concurrency safe. Move them under MAC80211_DEBUG_COUNTERS so they're normally not even compiled in. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* | mac80211: clean up global debugfs statisticsJohannes Berg2015-05-051-1/+1
| | | | | | | | | | | | | | | | | | The debugfs statistics macros are pointlessly verbose, so change that macro to just have a single argument. While at it, remove the unused counters and rename rx_expand_skb_head2 to the better rx_expand_skb_head_defrag. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* | mac80211: notify the driver on reordering buffer timeoutEmmanuel Grumbach2015-04-241-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | When frames time out in the reordering buffer, it is a good indication that something went wrong and the driver may want to know about that to take action or trigger debug flows. It is pointless to notify the driver about each frame that is released. Notify each time the timer fires. Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* | mac80211: notify the driver upon BAR RxEmmanuel Grumbach2015-04-241-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When we receive a BAR, this typically means that our peer doesn't hear our Block-Acks or that we can't hear its frames. Either way, it is a good indication that the link is in a bad condition. This is why it can serve as a probe to the driver. Use the event_callback callback for this. Since more events with the same data will be added in the feature, the structure that describes the data attached to the event is called in a generic name: ieee80211_ba_event. This also means that from now on, the event_callback can't sleep. Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* | mac80211: use per-CPU TX/RX statisticsJohannes Berg2015-04-241-7/+14
| | | | | | | | | | | | | | | | | | This isn't all that relevant for RX right now, but TX can be concurrent due to multi-queue and the accounting is therefore broken. Use the standard per-CPU statistics to avoid this. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* | mac80211: OCB: remove pointless check for broadcast BSSIDJohannes Berg2015-04-241-5/+1
| | | | | | | | | | | | | | The OCB input path already checked that the BSSID is the broadcast address, so the later check can never fail. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* | mac80211: clean up/rename prepare_for_handlers()Johannes Berg2015-04-241-44/+36
| | | | | | | | | | | | | | | | The function really shouldn't be called prepare_for_handlers(), all it does is check if the frame should be dropped. Rename it to ieee80211_accept_frame() and clean it up a bit. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* | mac80211: remove IEEE80211_RX_RA_MATCHJohannes Berg2015-04-241-39/+5
| | | | | | | | | | | | | | | | With promisc support gone, only AP and P2P-Device type interfaces still clear IEEE80211_RX_RA_MATCH. In both cases this isn't really necessary though, so we can remove that flag and the code. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* | mac80211: remove support for IFF_PROMISCJohannes Berg2015-04-241-25/+8
| | | | | | | | | | | | | | | | | | | | | | This support is essentially useless as typically networks are encrypted, frames will be filtered by hardware, and rate scaling will be done with the intended recipient in mind. For real monitoring of the network, the monitor mode support should be used instead. Removing it removes a lot of corner cases. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* | mac80211: add TX fastpathJohannes Berg2015-04-221-0/+2
|/ | | | | | | | | | | | In order to speed up mac80211's TX path, add the "fast-xmit" cache that will cache the data frame 802.11 header and other data to be able to build the frame more quickly. This cache is rebuilt when external triggers imply changes, but a lot of the checks done per packet today are simplified away to the check for the cache. There's also a more detailed description in the code. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* Merge tag 'mac80211-next-for-davem-2015-04-10' of ↵David S. Miller2015-04-121-2/+20
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next Johannes Berg says: ==================== There isn't much left, but we have * new mac80211 internal software queue to allow drivers to have shorter hardware queues and pull on-demand * use rhashtable for mac80211 station table * minstrel rate control debug improvements and some refactoring * fix noisy message about TX power reduction * fix continuous message printing and activity if CRDA doesn't respond * fix VHT-related capabilities with "iw connect" or "iwconfig ..." * fix Kconfig for cfg80211 wireless extensions compatibility ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
| * mac80211: add an intermediate software queue implementationFelix Fietkau2015-04-011-0/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This allows drivers to request per-vif and per-sta-tid queues from which they can pull frames. This makes it easier to keep the hardware queues short, and to improve fairness between clients and vifs. The task of scheduling packet transmission is left up to the driver - queueing is controlled by mac80211. Drivers can only dequeue packets by calling ieee80211_tx_dequeue. This makes it possible to add active queue management later without changing drivers using this code. This can also be used as a starting point to implement A-MSDU aggregation in a way that does not add artificially induced latency. Signed-off-by: Felix Fietkau <nbd@openwrt.org> [resolved minor context conflict, minor changes, endian annotations] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
| * mac80211: use rhashtable for station tableJohannes Berg2015-04-011-2/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We currently have a hand-rolled table with 256 entries and are using the last byte of the MAC address as the hash. This hash is obviously very fast, but collisions are easily created and we waste a lot of space in the common case of just connecting as a client to an AP where we just have a single station. The other common case of an AP is also suboptimal due to the size of the hash table and the ease of causing collisions. Convert all of this to use rhashtable with jhash, which gives us the advantage of a far better hash function (with random perturbation to avoid hash collision attacks) and of course that the hash table grows and shrinks dynamically with chain length, improving both cases above. Use a specialised hash function (using jhash, but with fixed length) to achieve better compiler optimisation as suggested by Sergey Ryazanov. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* | Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/netDavid S. Miller2015-04-021-3/+4
|\ \ | |/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Conflicts: drivers/net/usb/asix_common.c drivers/net/usb/sr9800.c drivers/net/usb/usbnet.c include/linux/usb/usbnet.h net/ipv4/tcp_ipv4.c net/ipv6/tcp_ipv6.c The TCP conflicts were overlapping changes. In 'net' we added a READ_ONCE() to the socket cached RX route read, whilst in 'net-next' Eric Dumazet touched the surrounding code dealing with how mini sockets are handled. With USB, it's a case of the same bug fix first going into net-next and then I cherry picked it back into net. Signed-off-by: David S. Miller <davem@davemloft.net>
| * mac80211: fix RX A-MPDU session reorder timer deletionJohannes Berg2015-04-011-3/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There's an issue with the way the RX A-MPDU reorder timer is deleted that can cause a kernel crash like this: * tid_rx is removed - call_rcu(ieee80211_free_tid_rx) * station is destroyed * reorder timer fires before ieee80211_free_tid_rx() runs, accessing the station, thus potentially crashing due to the use-after-free The station deletion is protected by synchronize_net(), but that isn't enough -- ieee80211_free_tid_rx() need not have run when that returns (it deletes the timer.) We could use rcu_barrier() instead of synchronize_net(), but that's much more expensive. Instead, to fix this, add a field tracking that the session is being deleted. In this case, the only re-arming of the timer happens with the reorder spinlock held, so make that code not rearm it if the session is being deleted and also delete the timer after setting that field. This ensures the timer cannot fire after ___ieee80211_stop_rx_ba_session() returns, which fixes the problem. Cc: stable@vger.kernel.org Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* | Merge tag 'mac80211-next-for-davem-2015-03-30' of ↵David S. Miller2015-03-311-7/+10
|\ \ | |/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next Johannes Berg says: ==================== Lots of updates for net-next; along with the usual flurry of small fixes, cleanups and internal features we have: * VHT support for TDLS and IBSS (conditional on drivers though) * first TX performance improvements (the biggest will come later) * many suspend/resume (race) fixes * name_assign_type support from Tom Gundersen ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
| * mac80211: remove drop_unencrypted codeJohannes Berg2015-03-201-2/+1
| | | | | | | | | | | | | | | | | | | | This mechanism was historic, and only ever used by IBSS, which also doesn't need to have it as it properly manages station's 802.1X PAE state (or, with WEP, always has a key.) Remove the mechanism to clean up the code. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
| * mac80211: add comment for rx_path_lockJohannes Berg2015-03-161-0/+6
| | | | | | | | | | | | Add a comment explaining how the RX path lock is used. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
| * mac80211: move netdev stats to common functionJohannes Berg2015-03-161-5/+3
| | | | | | | | | | | | | | Move the netdev stats accounting into the common function ieee80211_deliver_skb() that is called in both places. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* | mac80211: drop unencrypted frames in mesh fwdingBob Copeland2015-03-031-0/+3
|/ | | | | | | | | | | The mesh forwarding path was not checking that data frames were protected when running an encrypted network; add the necessary check. Cc: stable@vger.kernel.org Reported-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: Bob Copeland <me@bobcopeland.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* Merge tag 'mac80211-next-for-davem-2015-02-03' of ↵David S. Miller2015-02-041-10/+38
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next Last round of updates for net-next: * revert a patch that caused a regression with mesh userspace (Bob) * fix a number of suspend/resume related races (from Emmanuel, Luca and myself - we'll look at backporting later) * add software implementations for new ciphers (Jouni) * add a new ACPI ID for Broadcom's rfkill (Mika) * allow using netns FD for wireless (Vadim) * some other cleanups (various) Signed-off-by: David S. Miller <davem@davemloft.net>
| * mac80111: Add BIP-GMAC-128 and BIP-GMAC-256 ciphersJouni Malinen2015-01-271-0/+4
| | | | | | | | | | | | | | | | | | This allows mac80211 to configure BIP-GMAC-128 and BIP-GMAC-256 to the driver and also use software-implementation within mac80211 when the driver does not support this with hardware accelaration. Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
| * mac80111: Add BIP-CMAC-256 cipherJouni Malinen2015-01-271-5/+16
| | | | | | | | | | | | | | | | | | This allows mac80211 to configure BIP-CMAC-256 to the driver and also use software-implementation within mac80211 when the driver does not support this with hardware accelaration. Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
generated by cgit v1.2.3 (git 2.25.1) at 2024-12-27 09:33:18 +0000