1. 14 11月, 2018 5 次提交
    • L
      iwlwifi: mvm: check return value of rs_rate_from_ucode_rate() · 3fa27214
      Luca Coelho 提交于
      commit 3d71c3f1f50cf309bd20659422af549bc784bfff upstream.
      
      The rs_rate_from_ucode_rate() function may return -EINVAL if the rate
      is invalid, but none of the callsites check for the error, potentially
      making us access arrays with index IWL_RATE_INVALID, which is larger
      than the arrays, causing an out-of-bounds access.  This will trigger
      KASAN warnings, such as the one reported in the bugzilla issue
      mentioned below.
      
      This fixes https://bugzilla.kernel.org/show_bug.cgi?id=200659
      
      Cc: stable@vger.kernel.org
      Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
      Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3fa27214
    • S
      iwlwifi: mvm: fix BAR seq ctrl reporting · 8ba36c16
      Sara Sharon 提交于
      [ Upstream commit 941ab4eb66c10bc5c7234e83a7a858b2806ed151 ]
      
      There is a bug in FW where the sequence control may be
      incorrect, and the driver overrides it with the value
      of the ieee80211 header.
      
      However, in BAR there is no sequence control in the header,
      which result with arbitrary sequence.
      
      This access to an unknown location is bad and it makes the
      logs very confusing - so fix it.
      Signed-off-by: NSara Sharon <sara.sharon@intel.com>
      Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      8ba36c16
    • L
      iwlwifi: mvm: check for n_profiles validity in EWRD ACPI · a2abae52
      Luca Coelho 提交于
      [ Upstream commit 2e1976bb75263fbad918e82184b16a23bd721546 ]
      
      When reading the profiles from the EWRD table in ACPI, we loop over
      the data and set it into our internal table.  We use the number of
      profiles specified in ACPI without checking its validity, so if the
      ACPI table is corrupted and the number is larger than our array size,
      we will try to make an out-of-bounds access.
      
      Fix this by making sure the value specified in the ACPI table is
      valid.
      
      Fixes: 69964905 ("iwlwifi: mvm: add support for EWRD (Dynamic SAR) ACPI table")
      Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a2abae52
    • E
      iwlwifi: mvm: clear HW_RESTART_REQUESTED when stopping the interface · b325d550
      Emmanuel Grumbach 提交于
      [ Upstream commit 155f7e0441cd121b1e673d465a35e99f4b9b2f0b ]
      
      Fix a bug that happens in the following scenario:
      1) suspend without WoWLAN
      2) mac80211 calls drv_stop because of the suspend
      3) __iwl_mvm_mac_stop deallocates the aux station
      4) during drv_stop the firmware crashes
      5) iwlmvm:
      	* sets IWL_MVM_STATUS_HW_RESTART_REQUESTED
      	* asks mac80211 to kick the restart flow
      6) mac80211 puts the restart worker into a freezable
         queue which means that the worker will not run for now
         since the workqueue is already frozen
      7) ...
      8) resume
      9) mac80211 runs ieee80211_reconfig as part of the resume
      10) mac80211 detects that a restart flow has been requested
          and that we are now resuming from suspend and cancels
          the restart worker
      11) mac80211 calls drv_start()
      12) __iwl_mvm_mac_start checks that IWL_MVM_STATUS_HW_RESTART_REQUESTED
          clears it, sets IWL_MVM_STATUS_IN_HW_RESTART and calls
          iwl_mvm_restart_cleanup()
      13) iwl_fw_error_dump gets called and accesses the device
          to get debug data
      14) iwl_mvm_up adds the aux station
      15) iwl_mvm_add_aux_sta() allocates an internal station for
          the aux station
      16) iwl_mvm_allocate_int_sta() tests IWL_MVM_STATUS_IN_HW_RESTART
          and doesn't really allocate a station ID for the aux
          station
      17) a new queue is added for the aux station
      
      Note that steps from 5 to 9 aren't really part of the
      problem but were described for the sake of completeness.
      
      Once the iwl_mvm_mac_stop() is called, the device is not
      accessible, meaning that step 12) can't succeed and we'll
      see the following:
      
      drivers/net/wireless/intel/iwlwifi/pcie/trans.c:2122 iwl_trans_pcie_grab_nic_access+0xc0/0x1d6 [iwlwifi]()
      Timeout waiting for hardware access (CSR_GP_CNTRL 0x080403d8)
      Call Trace:
      [<ffffffffc03e6ad3>] iwl_trans_pcie_grab_nic_access+0xc0/0x1d6 [iwlwifi]
      [<ffffffffc03e6a13>] iwl_trans_pcie_dump_regs+0x3fd/0x3fd [iwlwifi]
      [<ffffffffc03dad42>] iwl_fw_error_dump+0x4f5/0xe8b [iwlwifi]
      [<ffffffffc04bd43e>] __iwl_mvm_mac_start+0x5a/0x21a [iwlmvm]
      [<ffffffffc04bd6d2>] iwl_mvm_mac_start+0xd4/0x103 [iwlmvm]
      [<ffffffffc042d378>] drv_start+0xa1/0xc5 [iwl7000_mac80211]
      [<ffffffffc045a339>] ieee80211_reconfig+0x145/0xf50 [mac80211]
      [<ffffffffc044788b>] ieee80211_resume+0x62/0x66 [mac80211]
      [<ffffffffc0366c5b>] wiphy_resume+0xa9/0xc6 [cfg80211]
      
      The station id of the aux station is set to 0xff in step 3
      and because we don't really allocate a new station id for
      the auxliary station (as explained in 16), we end up sending
      a command to the firmware asking to connect the queue
      to station id 0xff. This makes the firmware crash with the
      following information:
      
      0x00002093 | ADVANCED_SYSASSERT
      0x000002F0 | trm_hw_status0
      0x00000000 | trm_hw_status1
      0x00000B38 | branchlink2
      0x0001978C | interruptlink1
      0x00000000 | interruptlink2
      0xFF080501 | data1
      0xDEADBEEF | data2
      0xDEADBEEF | data3
      Firmware error during reconfiguration - reprobe!
      FW error in SYNC CMD SCD_QUEUE_CFG
      
      Fix this by clearing IWL_MVM_STATUS_HW_RESTART_REQUESTED
      in iwl_mvm_mac_stop(). We won't be able to collect debug
      data anyway and when we will brought up again, we will
      have a clean state from the firmware perspective.
      Since we won't have IWL_MVM_STATUS_IN_HW_RESTART set in
      step 12) we won't get to the 2093 ASSERT either.
      
      Fixes: bf8b286f ("iwlwifi: mvm: defer setting IWL_MVM_STATUS_IN_HW_RESTART")
      Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b325d550
    • S
      iwlwifi: pcie: avoid empty free RB queue · 0ba5fac2
      Shaul Triebitz 提交于
      [ Upstream commit 868a1e863f95183f00809363fefba6d4f5bcd116 ]
      
      If all free RB queues are empty, the driver will never restock the
      free RB queue.  That's because the restocking happens in the Rx flow,
      and if the free queue is empty there will be no Rx.
      
      Although there's a background worker (a.k.a. allocator) allocating
      memory for RBs so that the Rx handler can restock them, the worker may
      run only after the free queue has become empty (and then it is too
      late for restocking as explained above).
      
      There is a solution for that called 'emergency': If the number of used
      RB's reaches half the amount of all RB's, the Rx handler will not wait
      for the allocator but immediately allocate memory for the used RB's
      and restock the free queue.
      
      But, since the used RB's is per queue, it may happen that the used
      RB's are spread between the queues such that the emergency check will
      fail for each of the queues
      (and still run out of RBs, causing the above symptom).
      
      To fix it, move to emergency mode if the sum of *all* used RBs (for
      all Rx queues) reaches half the amount of all RB's
      Signed-off-by: NShaul Triebitz <shaul.triebitz@intel.com>
      Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0ba5fac2
  2. 28 9月, 2018 1 次提交
  3. 28 8月, 2018 1 次提交
    • S
      cfg80211: make wmm_rule part of the reg_rule structure · 38cb87ee
      Stanislaw Gruszka 提交于
      Make wmm_rule be part of the reg_rule structure. This simplifies the
      code a lot at the cost of having bigger memory usage. However in most
      cases we have only few reg_rule's and when we do have many like in
      iwlwifi we do not save memory as it allocates a separate wmm_rule for
      each channel anyway.
      
      This also fixes a bug reported in various places where somewhere the
      pointers were corrupted and we ended up doing a null-dereference.
      
      Fixes: 230ebaa1 ("cfg80211: read wmm rules from regulatory database")
      Signed-off-by: NStanislaw Gruszka <sgruszka@redhat.com>
      [rephrase commit message slightly]
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      38cb87ee
  4. 07 8月, 2018 1 次提交
  5. 02 8月, 2018 16 次提交
  6. 26 7月, 2018 16 次提交