1. 05 Feb, 2020 1 commit
    • Jouni Malinen's avatar
      mac80211: Fix TKIP replay protection immediately after key setup · b308d93d
      Jouni Malinen authored
      [ Upstream commit 6f601265
      
       ]
      
      TKIP replay protection was skipped for the very first frame received
      after a new key is configured. While this is potentially needed to avoid
      dropping a frame in some cases, this does leave a window for replay
      attacks with group-addressed frames at the station side. Any earlier
      frame sent by the AP using the same key would be accepted as a valid
      frame and the internal RSC would then be updated to the TSC from that
      frame. This would allow multiple previously transmitted group-addressed
      frames to be replayed until the next valid new group-addressed frame
      from the AP is received by the station.
      
      Fix this by limiting the no-replay-protection exception to apply only
      for the case where TSC=0, i.e., when this is for the very first frame
      protected using the new key, and the local RSC had not been set to a
      higher value when configuring the key (which may happen with GTK).
      Signed-off-by: default avatarJouni Malinen <j@w1.fi>
      Link: https://lore.kernel.org/r/20200107153545.10934-1-j@w1.fi
      
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      b308d93d
  2. 20 Jun, 2019 1 commit
  3. 19 Jun, 2019 1 commit
  4. 24 Feb, 2016 1 commit
    • Eliad Peller's avatar
      mac80211: move TKIP TX IVs to public part of key struct · f8079d43
      Eliad Peller authored
      
      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: default avatarEliad Peller <eliadx.peller@intel.com>
      Signed-off-by: default avatarEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      f8079d43
  5. 18 Dec, 2013 1 commit
  6. 16 May, 2013 1 commit
  7. 15 Feb, 2013 1 commit
  8. 22 Jun, 2012 1 commit
  9. 05 Jun, 2012 1 commit
  10. 31 Oct, 2011 1 commit
  11. 15 Jul, 2011 1 commit
  12. 08 Jul, 2011 2 commits
    • Johannes Berg's avatar
      mac80211: allow driver to generate P1K for IV32 · 42d98795
      Johannes Berg authored
      
      In order to support pre-populating the P1K cache in
      iwlwifi hardware for WoWLAN, we need to calculate
      the P1K for the current IV32. Allow drivers to get
      the P1K for any given IV32 instead of for a given
      packet, but keep the packet-based version around as
      an inline.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      42d98795
    • Johannes Berg's avatar
      mac80211: fix TKIP races, make API easier to use · 523b02ea
      Johannes Berg authored
      
      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: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      523b02ea
  13. 04 Apr, 2011 1 commit
  14. 08 Jul, 2010 1 commit
    • John W. Linville's avatar
      mac80211: remove wep dependency · 3473187d
      John W. Linville authored
      
      The current mac80211 code assumes that WEP is always available.  If WEP
      fails to initialize, ieee80211_register_hw will always fail.
      
      In some cases (e.g. FIPS certification), the cryptography used by WEP is
      unavailable.  However, in such cases there is no good reason why CCMP
      encryption (or even no link level encryption) cannot be used.  So, this
      patch removes mac80211's assumption that WEP (and TKIP) will always be
      available for use.
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      3473187d
  15. 22 Jan, 2010 1 commit
  16. 19 Jan, 2010 1 commit
    • Johannes Berg's avatar
      mac80211: move control.hw_key assignment · 813d7669
      Johannes Berg authored
      
      When mac80211 asks a driver to encrypt a frame, it
      must assign the control.hw_key pointer for it to
      know which key to use etc. Currently, mac80211 does
      this whenever it would software-encrypt a frame.
      
      Change the logic of this code to assign the hw_key
      pointer when selecting the key, and later check it
      when deciding whether to encrypt the frame or let
      it be encrypted by the hardware. This allows us to
      later simply skip the encryption function since it
      no longer modifies the TX control.
      Signed-off-by: default avatarJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      813d7669
  17. 22 Dec, 2009 1 commit
  18. 18 Nov, 2009 1 commit
  19. 06 May, 2009 1 commit
  20. 28 Oct, 2008 1 commit
  21. 15 Sep, 2008 1 commit
  22. 27 Jun, 2008 2 commits
  23. 14 Jun, 2008 3 commits
  24. 22 May, 2008 4 commits
  25. 14 May, 2008 1 commit
  26. 01 May, 2008 1 commit
  27. 08 Apr, 2008 1 commit
  28. 25 Mar, 2008 2 commits
  29. 10 Oct, 2007 3 commits
  30. 05 May, 2007 1 commit