linux-stable.git/drivers/net/wireless/intel, branch v4.14.76

iwlwifi: add more card IDs for 9000 series

2018-08-06T14:20:51+00:00

commit 0a5257bc6d89c2ae69b9bf955679cb4f89261874 upstream.

Add new device IDs for the 9000 series.

Cc: stable@vger.kernel.org # 4.14
Signed-off-by: Emmanuel Grumbach 
Signed-off-by: Kalle Valo 
Signed-off-by: Greg Kroah-Hartman

iwlwifi: pcie: fix race in Rx buffer allocator

2018-08-03T05:50:27+00:00

[ Upstream commit 0f22e40053bd5378ad1e3250e65c574fd61c0cd6 ]

Make sure the rx_allocator worker is canceled before running the
rx_init routine.  rx_init frees and re-allocates all rxb's pages.  The
rx_allocator worker also allocates pages for the used rxb's.  Running
rx_init and rx_allocator simultaniously causes a kernel panic.  Fix
that by canceling the work in rx_init.

Signed-off-by: Shaul Triebitz 
Signed-off-by: Luca Coelho 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

iwlwifi: pcie: compare with number of IRQs requested for, not number of CPUs

2018-07-08T13:30:52+00:00

[ Upstream commit ab1068d6866e28bf6427ceaea681a381e5870a4a ]

When there are 16 or more logical CPUs, we request for
`IWL_MAX_RX_HW_QUEUES` (16) IRQs only as we limit to that number of
IRQs, but later on we compare the number of IRQs returned to
nr_online_cpus+2 instead of max_irqs, the latter being what we
actually asked for. This ends up setting num_rx_queues to 17 which
causes lots of out-of-bounds array accesses later on.

Compare to max_irqs instead, and also add an assertion in case
num_rx_queues > IWM_MAX_RX_HW_QUEUES.

This fixes https://bugzilla.kernel.org/show_bug.cgi?id=199551

Fixes: 2e5d4a8f61dc ("iwlwifi: pcie: Add new configuration to enable MSIX")
Signed-off-by: Hao Wei Tee 
Tested-by: Sara Sharon 
Signed-off-by: Luca Coelho 
Signed-off-by: Kalle Valo 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

iwlwifi: fw: harden page loading code

2018-06-26T00:06:33+00:00

commit 9039d985811d5b109b58b202b7594fd24e433fed upstream.

The page loading code trusts the data provided in the firmware images
a bit too much and may cause a buffer overflow or copy unknown data if
the block sizes don't match what we expect.

To prevent potential problems, harden the code by checking if the
sizes we are copying are what we expect.

Cc: stable@vger.kernel.org
Signed-off-by: Luca Coelho 
Signed-off-by: Greg Kroah-Hartman

iwlwifi: mvm: check if mac80211_queue is valid in iwl_mvm_disable_txq

2018-05-30T05:52:28+00:00

[ Upstream commit 9a233bb8025105db9a60b5d761005cc5a6c77f3d ]

Sometimes iwl_mvm_disable_txq() may be called with mac80211_queue ==
IEEE80211_INVAL_HW_QUEUE, and this would cause us to use BIT(0xFF)
which is way too large for the u16 we used to store it in
hw_queue_to_mac820211.  If this happens the following UBSAN warning
will be generated:

[  167.185167] UBSAN: Undefined behaviour in drivers/net/wireless/intel/iwlwifi/mvm/utils.c:838:5
[  167.185171] shift exponent 255 is too large for 64-bit type 'long unsigned int'

Fix that by checking that it is not IEEE80211_INVAL_HW_QUEUE and,
while at it, add a warning if the queue number is larger than
IEEE80211_MAX_QUEUES.

Fixes: 34e10860ae8d ("iwlwifi: mvm: remove references to queue_info in new TX path")
Reported-by: Paul Menzel 
Signed-off-by: Luca Coelho 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

iwlwifi: mvm: fix array out of bounds reference

2018-05-30T05:52:17+00:00

[ Upstream commit 4a6d2e525b43eba5870ea7e360f59aa65de00705 ]

When starting aggregation, the code checks the status of the queue
allocated to the aggregation tid, which might not yet be allocated
and thus the queue index may be invalid.
Fix this by reserving a new queue in case the queue id is invalid.

While at it, clean up some unreachable code (a condition that is
already handled earlier) and remove all the non-DQA comments since
non-DQA mode is no longer supported.

Fixes: cf961e16620f ("iwlwifi: mvm: support dqa-mode agg on non-shared queue")
Signed-off-by: Avraham Stern 
Signed-off-by: Luca Coelho 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

iwlwifi: mvm: make sure internal station has a valid id

2018-05-30T05:52:17+00:00

[ Upstream commit df65c8d1728adee2a52c30287d33da83a8c87480 ]

If the driver failed to resume from D3, it is possible that it has
no valid aux station. In such case, fw restart will end up in sending
station related commands with an invalid station id, which will
result in an assert.

Fix this by allocating a new station id for the aux station if it
does not have a valid id even in the case of fw restart.

Signed-off-by: Avraham Stern 
Signed-off-by: Luca Coelho 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

iwlwifi: mvm: clear tx queue id when unreserving aggregation queue

2018-05-30T05:52:17+00:00

[ Upstream commit 4b387906b1c3692bb790388c335515c0cf098a23 ]

When a queue is reserved for aggregation, the queue id is assigned
to the tid_data. This is fine since iwl_mvm_sta_tx_agg_oper()
takes care of allocating the queue before actual tx starts.
When the reservation is cancelled (e.g. when the AP declined the
aggregation request) the tid_data is not cleared. As a result,
following tx for this tid was trying to use an unallocated queue.

Fix this by setting the txq_id for the tid to invalid when unreserving
the queue.

Signed-off-by: Avraham Stern 
Signed-off-by: Luca Coelho 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

iwlwifi: mvm: Increase session protection time after CS

2018-05-30T05:52:16+00:00

[ Upstream commit 19125cb0591ae63cd4591e3dfe4c22058e748518 ]

After switching to a new channel, driver schedules session protection
time event in order to hear the beacon on the new channel.
The duration of the protection is two beacon intervals.
However, since we start to switch slightly before beacon with count 1, in
case we don't hear (or AP doesn't transmit) the very first beacon on the
new channel the protection ends without hearing any beacon at all.
At this stage the switch is not complete, the queues are closed and the
interface doesn't have quota yet or TBTT events. As the result, we are
stuck forever waiting for iwl_mvm_post_channel_switch() to be called.

Fix this by increasing the protection time to be 3 beacon intervals and
in addition drop the connection if the time event ends before we got any
beacon.

Signed-off-by: Andrei Otcheretianski 
Signed-off-by: Luca Coelho 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

iwlwifi: mvm: fix error checking for multi/broadcast sta

2018-05-30T05:52:15+00:00

[ Upstream commit 75fd4fec3e4c43b131c7c4958adb3ab9f1665513 ]

The earlier patch called the station add functions but didn't
assign their return value to the ret variable, so that the
checks for it were meaningless. Fix that.

Found by smatch:

.../mac80211.c:2560 iwl_mvm_start_ap_ibss() warn: we tested 'ret' before and it was 'false'
.../mac80211.c:2563 iwl_mvm_start_ap_ibss() warn: we tested 'ret' before and it was 'false'

Fixes: 3a89411cd31c ("iwlwifi: mvm: fix assert 0x2B00 on older FWs")
Signed-off-by: Johannes Berg 
Signed-off-by: Luca Coelho 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman