summaryrefslogtreecommitdiffstats
path: root/net/mac80211/wpa.c
Commit message (Collapse)AuthorAgeFilesLines
* mac80211: Add RX flag to indicate ICV strippedDavid Spinadel2017-01-121-1/+2
| | | | | | | | | Add a flag that indicates that the WEP ICV was stripped from an RX packet, allowing the device to not transfer that if it's already checked. Signed-off-by: David Spinadel <david.spinadel@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/netDavid S. Miller2016-10-301-13/+9
|\ | | | | | | | | | | | | | | | | Mostly simple overlapping changes. For example, David Ahern's adjacency list revamp in 'net-next' conflicted with an adjacency list traversal bug fix in 'net'. Signed-off-by: David S. Miller <davem@davemloft.net>
| * mac80211: move struct aead_req off the stackArd Biesheuvel2016-10-171-13/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Some crypto implementations (such as the generic CCM wrapper in crypto/) use scatterlists to map fields of private data in their struct aead_req. This means these data structures cannot live in the vmalloc area, which means that they cannot live on the stack (with CONFIG_VMAP_STACK.) This currently occurs only with the generic software implementation, but the private data and usage is implementation specific, so move the whole data structures off the stack into heap by allocating every time we need to use them. In addition, take care not to put any of our own stack allocations into scatterlists. This involves reserving some extra room when allocating the aead_request structures, and referring to those allocations in the scatter- lists (while copying the data from the stack before the crypto operation) Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* | mac80211: add a HW flag for supporting HW TX fragmentationSara Sharon2016-10-191-1/+1
|/ | | | | | | | | | | | | | | Currently mac80211 determines whether HW does fragmentation by checking whether the set_frag_threshold callback is set or not. However, some drivers may want to set the HW fragmentation capability depending on HW generation. Allow this by checking a HW flag instead of checking the callback. Signed-off-by: Sara Sharon <sara.sharon@intel.com> [added the flag to ath10k and wlcore] Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: allow same PN for AMSDU sub-framesSara Sharon2016-05-121-4/+12
| | | | | | | | | | | | Some hardware (iwlwifi an example) de-aggregate AMSDUs and copy the IV as is to the generated MPDUs, so the same PN appears in multiple packets without being a replay attack. Allow driver to explicitly indicate that a frame is allowed to have the same PN as the previous frame. Signed-off-by: Sara Sharon <sara.sharon@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: allow not sending MIC up from driver for HW cryptoSara Sharon2016-04-051-12/+14
| | | | | | | | | | | | | | | When HW crypto is used, there's no need for the CCMP/GCMP MIC to be available to mac80211, and the hardware might have removed it already after checking. The MIC is also useless to have when the frame is already decrypted, so allow indicating that it's not present. Since we are running out of bits in mac80211_rx_flags, make the flags field a u64. Signed-off-by: Sara Sharon <sara.sharon@intel.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: move TKIP TX IVs to public part of key structEliad Peller2016-02-241-7/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | Some drivers/devices might want to set the IVs by themselves (and still let mac80211 generate MMIC). Specifically, this is needed when the device does offloading at certain times, and the driver has to make sure that the IVs of new tx frames (from the host) are synchronized with IVs that were potentially used during the offloading. Similarly to CCMP, move the TX IVs of TKIP keys to the public part of the key struct, and export a function to add the IV right into the crypto header. The public tx_pn field is defined as atomic64, so define TKIP_PN_TO_IV16/32 helper macros to convert it to iv16/32 when needed. Since the iv32 used for the p1k cache is taken directly from the frame, we can safely remove iv16/32 from being protected by tkip.txlock. Signed-off-by: Eliad Peller <eliadx.peller@intel.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: remove event.cJohannes Berg2015-10-141-3/+6
| | | | | | | That file contains just a single function, which itself is just a single statement to call a different function. Remove it. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: support device/driver PN check for CCMP/GCMPJohannes Berg2015-07-171-38/+45
| | | | | | | | | | | | | | When there are multiple RX queues, the PN checks in mac80211 cannot be used since packets might be processed out of order on different CPUs. Allow the driver to report that the PN has been checked, drivers that will use multi-queue RX will have to set this flag. For now, the flag is only valid when the frame has been decrypted, in theory that restriction doesn't have to be there, but in practice the hardware will have decrypted the frame already. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: move TX PN to public part of key structJohannes Berg2015-06-021-5/+5
| | | | | | | | | | | | | | | | | | | | | | | | For drivers supporting TSO or similar features, but that still have PN assignment in software, there's a need to have some memory to store the current PN value. As mac80211 already stores this and it's somewhat complicated to add a per-driver area to the key struct (due to the dynamic sizing thereof) it makes sense to just move the TX PN to the keyconf, i.e. the public part of the key struct. As TKIP is more complicated and we won't able to offload it in this way right now (fast-xmit is skipped for TKIP unless the HW does it all, and our hardware needs MMIC calculation in software) I've not moved that for now - it's possible but requires exposing a lot of the internal TKIP state. As an bonus side effect, we can remove a lot of code by assuming the keyseq struct has a certain layout - with BUILD_BUG_ON to verify it. This might also improve performance, since now TX and RX no longer share a cacheline. Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: Get IV len from key conf and not cipher schemeCedric Izoard2015-03-171-7/+6
| | | | | | | | | | | | | | | When a key is installed using a cipher scheme, set a new internal key flag (KEY_FLAG_CIPHER_SCHEME) on it, to allow distinguishing such keys more easily. In particular, use this flag on the TX path instead of testing the sta->cipher_scheme pointer, as the station is NULL for broad-/multicast message, and use the key's iv_len instead of the cipher scheme information. Signed-off-by: Cedric Izoard <cedric.izoard@ceva-dsp.com> [add missing documentation, rewrite commit message] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80111: Add BIP-GMAC-128 and BIP-GMAC-256 ciphersJouni Malinen2015-01-271-0/+105
| | | | | | | | | 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-0/+92
| | | | | | | | | 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>
* mac80111: Add CCMP-256 cipherJouni Malinen2015-01-271-10/+12
| | | | | | | | | | This allows mac80211 to configure CCMP-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> [squash ccmp256 -> mic_len argument change] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80111: Add GCMP and GCMP-256 ciphersJouni Malinen2015-01-271-0/+224
| | | | | | | | | | This allows mac80211 to configure GCMP and GCMP-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> [remove a spurious newline] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: fix network header breakage during encryptionArik Nemtsov2014-10-231-5/+0
| | | | | | | | | | When an IV is generated, only the MAC header is moved back. The network header location remains the same relative to the skb head, as the new IV is using headroom space that was reserved in advance. 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: annotate MMIC head/tailroom warningJohannes Berg2014-09-081-2/+5
| | | | | | | | | This message occasionally triggers for some people as in https://bugzilla.redhat.com/show_bug.cgi?id=1111740 but it's not clear which (headroom or tailroom) is at fault. Annotate the message a bit to get more information. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: fix a potential NULL access in ieee80211_crypto_hw_decryptMax Stepanov2014-07-211-1/+1
| | | | | | | | | | | | | | | | | The NULL pointer access could happen when ieee80211_crypto_hw_decrypt is called from ieee80211_rx_h_decrypt with the following condition: 1. rx->key->conf.cipher is not WEP, CCMP, TKIP or AES_CMAC 2. rx->sta is NULL When ieee80211_crypto_hw_decrypt is called, it verifies rx->sta->cipher_scheme and it will cause Oops if rx->sta is NULL. This path adds an addirional rx->sta == NULL verification in ieee80211_crypto_hw_decrypt for this case. Signed-off-by: Max Stepanov <Max.Stepanov@intel.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: add option to generate CCMP IVs only for mgmt framesMarek Kwaczynski2014-04-251-1/+4
| | | | | | | | | | Some chips can encrypt managment frames in HW, but require generated IV in the frame. Add a key flag that allows us to achieve this. Signed-off-by: Marek Kwaczynski <marek.kwaczynski@tieto.com> [use BIT(0) to fill that spot, fix indentation] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: add length check in ieee80211_is_robust_mgmt_frame()Johannes Berg2014-02-041-1/+1
| | | | | | | | | | | A few places weren't checking that the frame passed to the function actually has enough data even though the function clearly documents it must have a payload byte. Make this safer by changing the function to take an skb and checking the length inside. The old version is preserved for now as the rtl* drivers use it and don't have a correct skb. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: drop unused param 'encrypted' from ccmp_special_blocks()Ard Biesheuvel2014-02-041-4/+3
| | | | | | | | | Commit 7ec7c4a9a686 ("mac80211: port CCMP to cryptoapi's CCM driver") resulted in the 'encrypted' param of ccmp_special_blocks() to be no longer used so it can be dropped from the prototype. Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: clean up garbage in commentEmmanuel Grumbach2014-01-071-1/+1
| | | | | | | Not clear how this landed here. Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: add generic cipher scheme supportMax Stepanov2013-11-251-0/+116
| | | | | | | | | | | | This adds generic cipher scheme support to mac80211, such schemes are fully under control by the driver. On hw registration drivers may specify additional HW ciphers with a scheme how these ciphers have to be handled by mac80211 TX/RR. A cipher scheme specifies a cipher suite value, a size of the security header to be added to or stripped from frames and how the PN is to be verified on RX. Signed-off-by: Max Stepanov <Max.Stepanov@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: port CCMP to cryptoapi's CCM driverArd Biesheuvel2013-10-111-24/+20
| | | | | | | | | | | Use the generic CCM aead chaining mode driver rather than a local implementation that sits right on top of the core AES cipher. This allows the use of accelerated implementations of either CCM as a whole or the CTR mode which it encapsulates. Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* wireless: move crypto constants to ieee80211.hJohannes Berg2013-05-161-32/+36
| | | | | | | | mac80211 and the Intel drivers all define crypto constants, move them to ieee80211.h instead. Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: use spin_lock_bh() for TKIP lockJohannes Berg2013-02-151-3/+2
| | | | | | | | | Since no driver calls the TKIP functions from interrupt context, there's no need to use spin_lock_irqsave(). Just use spin_lock_bh() (and spin_lock() in the TX path where we're in a BH or they're already disabled.) Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: add debug file for mic failureSaravana2012-12-051-1/+4
| | | | | | | | | | The mic failure count provides the number of mic failures that have happened on a given key (without a countermeasure being started, since that would remove the key). Signed-off-by: Saravana <saravanad@posedge.com> [fix NULL pointer issues] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* Merge branch 'for-john' of ↵John W. Linville2012-10-171-3/+8
|\ | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211
| * mac80211: Fix FC masking in BIP AAD generationJouni Malinen2012-10-011-3/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The bits used in the mask were off-by-one and ended up masking PwrMgt, MoreData, Protected fields instead of Retry, PwrMgt, MoreData. Fix this and to mask the correct fields. While doing so, convert the code to mask the full FC using IEEE80211_FCTL_* defines similarly to how CCMP AAD is built. Since BIP is used only with broadcast/multicast management frames, the Retry field is always 0 in these frames. The Protected field is also zero to maintain backwards compatibility. As such, the incorrect mask here does not really cause any problems for valid frames. In theory, an invalid BIP frame with Retry or Protected field set to 1 could be rejected because of BIP validation. However, no such frame should show up with standard compliant implementations, so this does not cause problems in normal BIP use. Signed-off-by: Jouni Malinen <j@w1.fi> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* | mac80211: check if key has TKIP type before updating IVStanislaw Gruszka2012-10-151-1/+2
|/ | | | | | | | | | | | | | | | | | | | | | | | This patch fix corruption which can manifest itself by following crash when switching on rfkill switch with rt2x00 driver: https://bugzilla.redhat.com/attachment.cgi?id=615362 Pointer key->u.ccmp.tfm of group key get corrupted in: ieee80211_rx_h_michael_mic_verify(): /* update IV in key information to be able to detect replays */ rx->key->u.tkip.rx[rx->security_idx].iv32 = rx->tkip_iv32; rx->key->u.tkip.rx[rx->security_idx].iv16 = rx->tkip_iv16; because rt2x00 always set RX_FLAG_MMIC_STRIPPED, even if key is not TKIP. We already check type of the key in different path in ieee80211_rx_h_michael_mic_verify() function, so adding additional check here is reasonable. Cc: stable@vger.kernel.org # 3.0+ Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* mac80211: fix network header location when adding encryption headersArik Nemtsov2012-05-161-0/+2
| | | | | | | | | Update the location of the network header when adding encryption specific headers to a skb. This allows low-level drivers to use the (now correct) location of the network header. Signed-off-by: Arik Nemtsov <arik@wizery.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* mac80211: Add IV-room in the skb for TKIP and WEPJanusz.Dziedzic@tieto.com2012-05-161-1/+7
| | | | | | | | | Add IV-room in skb also for TKIP and WEP. Extend patch: "mac80211: support adding IV-room in the skb for CCMP keys" Signed-off-by: Janusz Dziedzic <janusz.dziedzic@tieto.com> Acked-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* mac80211: linearize SKBs as needed for cryptoJohannes Berg2012-03-131-1/+21
| | | | | | | | | | | Not linearizing every SKB will help actually pass non-linear SKBs all the way up when on an encrypted connection. For now, linearize TKIP completely as it is lower performance and I don't quite grok all the details. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* mac80211: fix tx->skb NULL pointer dereferenceYoni Divinsky2012-01-161-0/+19
| | | | | | | | | | In function ieee80211_tx_h_encrypt the var info was initialized from tx->skb, since the fucntion is called after the function ieee80211_tx_h_fragment tx->skb is not valid anymore. Signed-off-by: Yoni Divinsky <yoni.divinsky@ti.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* mac80211: fix rx->key NULL pointer dereference in promiscuous modeStanislaw Gruszka2012-01-111-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | Since: commit 816c04fe7ef01dd9649f5ccfe796474db8708be5 Author: Christian Lamparter <chunkeey@googlemail.com> Date: Sat Apr 30 15:24:30 2011 +0200 mac80211: consolidate MIC failure report handling is possible to that we dereference rx->key == NULL when driver set RX_FLAG_MMIC_STRIPPED and not RX_FLAG_IV_STRIPPED and we are in promiscuous mode. This happen with rt73usb and rt61pci at least. Before the commit we always check rx->key against NULL, so I assume fix should be done in mac80211 (also mic_fail path has similar check). References: https://bugzilla.redhat.com/show_bug.cgi?id=769766 http://rt2x00.serialmonkey.com/pipermail/users_rt2x00.serialmonkey.com/2012-January/004395.html Cc: stable@vger.kernel.org # 3.0+ Reported-by: Stuart D Gathman <stuart@gathman.org> Reported-by: Kai Wohlfahrt <kai.scorpio@gmail.com> Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* mac80211: use skb list for fragmentsJohannes Berg2011-11-211-9/+16
| | | | | | | | | | | | | We are currently linking the skbs by using skb->next directly. This works, but the preferred way is to use a struct sk_buff_head instead. That also prepares for passing that to drivers directly. While at it I noticed we calculate the duration for fragments twice -- remove one of them. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* mac80211: make sure hw_key exists before checking its flagsArik Nemtsov2011-11-111-1/+2
| | | | | | | | | | | | | Fixes a bug introduced in: commit 077a9154898b374f20555adc3f620cccd02581d6 Author: Arik Nemtsov <arik@wizery.com> Date: Sun Oct 23 08:21:41 2011 +0200 Reported-by: Arend van Spriel <arend@broadcom.com> Reported-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: Arik Nemtsov <arik@wizery.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* mac80211: support adding IV-room in the skb for CCMP keysArik Nemtsov2011-11-081-1/+7
| | | | | | | | | Some cards can generate CCMP IVs in HW, but require the space for the IV to be pre-allocated in the frame at the correct offset. Add a key flag that allows us to achieve this. Signed-off-by: Arik Nemtsov <arik@wizery.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* mac80211: move fragment flag to info flag as dont-fragmentJohannes Berg2011-10-111-1/+2
| | | | | | | | | | | | | The purpose of this is two-fold: 1) by moving it out of tx_data.flags, we can in another patch move the radiotap parsing so it no longer is in the hotpath 2) if a device implements fragmentation but can optionally skip it, the radiotap request for not doing fragmentation may be honoured Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* mac80211: simplify RX PN/IV handlingJohannes Berg2011-07-081-5/+4
| | | | | | | | | | | | | | | | | | | | | | | | The current rx->queue value is slightly confusing. It is set to 16 on non-QoS frames, including data, and then used for sequence number and PN/IV checks. Until recently, we had a TKIP IV checking bug that had been introduced in 2008 to fix a seqno issue. Before that, we always used TID 0 for checking the PN or IV on non-QoS packets. Go back to the old status for PN/IV checks using the TID 0 counter for non-QoS by splitting up the rx->queue value into "seqno_idx" and "security_idx" in order to avoid confusion in the future. They each have special rules on the value used for non- QoS data frames. Since the handling is now unified, also revert the special TKIP handling from my patch "mac80211: fix TKIP replay vulnerability". Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* mac80211: use AES_BLOCK_SIZEJohannes Berg2011-07-081-5/+5
| | | | | | | | | mac80211 has a defnition of AES_BLOCK_SIZE and multiple definitions of AES_BLOCK_LEN. Remove them all and use crypto/aes.h. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* mac80211: fix CMAC racesJohannes Berg2011-07-081-13/+17
| | | | | | | | | | | | Just like TKIP and CCMP, CMAC has the PN race. It might not actually be possible to hit it now since there aren't multiple ACs for management frames, but fix it anyway. Also move scratch buffers onto the stack. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* mac80211: fix CCMP racesJohannes Berg2011-07-081-13/+19
| | | | | | | | | | | | | | | | | Since we can process multiple packets at the same time for different ACs, but the PN is allocated from a single counter, we need to use an atomic value there. Use atomic64_t to make this cheaper on 64-bit platforms, other platforms will support this through software emulation, see lib/atomic64.c. We also need to use an on-stack scratch buf so that multiple packets won't corrupt each others scratch buffers. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* mac80211: fix TKIP races, make API easier to useJohannes Berg2011-07-081-4/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Our current TKIP code races against itself on TX since we can process multiple packets at the same time on different ACs, but they all share the TX context for TKIP. This can lead to bad IVs etc. Also, the crypto offload helper code just obtains the P1K/P2K from the cache, and can update it as well, but there's no guarantee that packets are really processed in order. To fix these issues, first introduce a spinlock that will protect the IV16/IV32 values in the TX context. This first step makes sure that we don't assign the same IV multiple times or get confused in other ways. Secondly, change the way the P1K cache works. I add a field "p1k_iv32" that stores the value of the IV32 when the P1K was last recomputed, and if different from the last time, then a new P1K is recomputed. This can cause the P1K computation to flip back and forth if packets are processed out of order. All this also happens under the new spinlock. Finally, because there are argument differences, split up the ieee80211_get_tkip_key() API into ieee80211_get_tkip_p1k() and ieee80211_get_tkip_p2k() and give them the correct arguments. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* mac80211: fix rx->key NULL dereference during mic failureArik Nemtsov2011-06-271-1/+7
| | | | | | | | | | | | | | Sometimes when reporting a MIC failure rx->key may be unset. This code path is hit when receiving a packet meant for a multicast address, and decryption is performed in HW. Fortunately, the failing key_idx is not used for anything up to (and including) usermode, so we allow ourselves to drop it on the way up when a key cannot be retrieved. Signed-off-by: Arik Nemtsov <arik@wizery.com> Cc: stable@kernel.org Signed-off-by: John W. Linville <linville@tuxdriver.com>
* mac80211: consolidate MIC failure report handlingChristian Lamparter2011-05-021-14/+48
| | | | | | | | | | | | | | | | | | | | | | Currently, mac80211 handles MIC failures differently depending on whenever they are detected by the stack's own software crypto or when are handed down from the driver. This patch tries to unify both by moving the special branch out of mac80211 rx hotpath and into into the software crypto part. This has the advantage that we can run a few more sanity checks on the data and verify if the key type was TKIP. This is very handy because several devices generate false postive MIC failure reports. Like carl9170, ath9k and wl12xx: <http://www.spinics.net/lists/linux-wireless/msg68494.html> "mac80211: report MIC failure for truncated packets in AP mode" Cc: Luciano Coelho <coelho@ti.com> Cc: Arik Nemtsov <arik@wizery.com> Signed-off-by: Christian Lamparter <chunkeey@googlemail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* mac80211: Add testing functionality for TKIPJouni Malinen2011-02-031-0/+7
| | | | | | | | | | | | | | | | | | | | | | TKIP countermeasures depend on devices being able to detect Michael MIC failures on received frames and for stations to report errors to the AP. In order to test that behavior, it is useful to be able to send out TKIP frames with incorrect Michael MIC. This testing behavior has minimal effect on the TX path, so it can be added to mac80211 for convenient use. The interface for using this functionality is a file in mac80211 netdev debugfs (tkip_mic_test). Writing a MAC address to the file makes mac80211 generate a dummy data frame that will be sent out using invalid Michael MIC value. In AP mode, the address needs to be for one of the associated stations or ff:ff:ff:ff:ff:ff to use a broadcast frame. In station mode, the address can be anything, e.g., the current BSSID. It should be noted that this functionality works correctly only when associated and using TKIP. Signed-off-by: Jouni Malinen <jouni.malinen@atheros.com> Acked-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* mac80211: Remove obsolete TKIP flexibilityJouni Malinen2011-02-031-25/+7
| | | | | | | | | | | | | The TKIP implementation was originally prepared to be a bit more flexible in the way Michael MIC TX/RX keys are configured. However, we are now taking care of the TX/RX MIC key swapping in user space, so this code will not be needed. Similarly, there were some remaining WPA testing code that won't be used in their current form. Remove the unneeded extra complexity. Signed-off-by: Jouni Malinen <jouni.malinen@atheros.com> Reviewed-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* mac80211: move packet flags into packetJohannes Berg2010-09-271-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 8c0c709eea5cbab97fb464cd68b06f24acc58ee1 Author: Johannes Berg <johannes@sipsolutions.net> Date: Wed Nov 25 17:46:15 2009 +0100 mac80211: move cmntr flag out of rx flags moved the CMNTR flag into the skb RX flags for some aggregation cleanups, but this was wrong since the optimisation this flag tried to make requires that it is kept across the processing of multiple interfaces -- which isn't true for flags in the skb. The patch not only broke the optimisation, it also introduced a bug: under some (common!) circumstances the flag will be set on an already freed skb! However, investigating this in more detail, I found that most of the flags that we set should be per packet, _except_ for this one, due to a-MPDU processing. Additionally, the flags used for processing (currently just this one) need to be reset before processing a new packet. Since we haven't actually seen bugs reported as a result of the wrong flags handling (which is not too surprising -- the only real bug case I can come up with is an a-MSDU contained in an a-MPDU), I'll make a different fix for rc. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* mac80211: remove unused status flag checksJohannes Berg2010-08-161-20/+6
| | | | | | | | | | | | The decryption code verifies whether or not a given frame was decrypted and verified by hardware. This is unnecessary, as the crypto RX handler already does it long before the decryption code is even invoked, so remove that code to avoid confusion. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
OpenPOWER on IntegriCloud