linux-stable.git/drivers/net/wireless/intel, branch v5.5.7

iwlwifi: mvm: Check the sta is not NULL in iwl_mvm_cfg_he_sta()

2020-02-24T07:38:49+00:00

[ Upstream commit 12d47f0ea5e0aa63f19ba618da55a7c67850ca10 ]

Fix a kernel panic by checking that the sta is not NULL.
This could happen during a reconfig flow, as mac80211 moves the sta
between all the states without really checking if the previous state was
successfully set. So, if for some reason we failed to add back the
station, subsequent calls to sta_state() callback will be done when the
station is NULL. This would result in a following panic:

BUG: unable to handle kernel NULL pointer dereference at
0000000000000040
IP: iwl_mvm_cfg_he_sta+0xfc/0x690 [iwlmvm]
[..]
Call Trace:
 iwl_mvm_mac_sta_state+0x629/0x6f0 [iwlmvm]
 drv_sta_state+0xf4/0x950 [mac80211]
 ieee80211_reconfig+0xa12/0x2180 [mac80211]
 ieee80211_restart_work+0xbb/0xe0 [mac80211]
 process_one_work+0x1e2/0x610
 worker_thread+0x4d/0x3e0
[..]

Signed-off-by: Andrei Otcheretianski 
Signed-off-by: Luca Coelho 
Signed-off-by: Kalle Valo 
Signed-off-by: Sasha Levin

iwlwifi: mvm: Fix thermal zone registration

2020-02-24T07:38:49+00:00

[ Upstream commit baa6cf8450b72dcab11f37c47efce7c5b9b8ad0f ]

Use a unique name when registering a thermal zone. Otherwise, with
multiple NICS, we hit the following warning during the unregistration.

WARNING: CPU: 2 PID: 3525 at fs/sysfs/group.c:255
 RIP: 0010:sysfs_remove_group+0x80/0x90
 Call Trace:
  dpm_sysfs_remove+0x57/0x60
  device_del+0x5a/0x350
  ? sscanf+0x4e/0x70
  device_unregister+0x1a/0x60
  hwmon_device_unregister+0x4a/0xa0
  thermal_remove_hwmon_sysfs+0x175/0x1d0
  thermal_zone_device_unregister+0x188/0x1e0
  iwl_mvm_thermal_exit+0xe7/0x100 [iwlmvm]
  iwl_op_mode_mvm_stop+0x27/0x180 [iwlmvm]
  _iwl_op_mode_stop.isra.3+0x2b/0x50 [iwlwifi]
  iwl_opmode_deregister+0x90/0xa0 [iwlwifi]
  __exit_compat+0x10/0x2c7 [iwlmvm]
  __x64_sys_delete_module+0x13f/0x270
  do_syscall_64+0x5a/0x110
  entry_SYSCALL_64_after_hwframe+0x44/0xa9

Signed-off-by: Andrei Otcheretianski 
Signed-off-by: Luca Coelho 
Signed-off-by: Kalle Valo 
Signed-off-by: Sasha Levin

iwlegacy: ensure loop counter addr does not wrap and cause an infinite loop

2020-02-24T07:38:43+00:00

[ Upstream commit c2f9a4e4a5abfc84c01b738496b3fd2d471e0b18 ]

The loop counter addr is a u16 where as the upper limit of the loop
is an int. In the unlikely event that the il->cfg->eeprom_size is
greater than 64K then we end up with an infinite loop since addr will
wrap around an never reach upper loop limit. Fix this by making addr
an int.

Addresses-Coverity: ("Infinite loop")
Fixes: be663ab67077 ("iwlwifi: split the drivers for agn and legacy devices 3945/4965")
Signed-off-by: Colin Ian King 
Acked-by: Stanislaw Gruszka 
Signed-off-by: Kalle Valo 
Signed-off-by: Sasha Levin

iwlegacy: Fix -Wcast-function-type

2020-02-24T07:38:17+00:00

[ Upstream commit da5e57e8a6a3e69dac2937ba63fa86355628fbb2 ]

correct usage prototype of callback in tasklet_init().
Report by https://github.com/KSPP/linux/issues/20

Signed-off-by: Phong Tran 
Reviewed-by: Kees Cook 
Signed-off-by: Kalle Valo 
Signed-off-by: Sasha Levin

ipw2x00: Fix -Wcast-function-type

2020-02-24T07:38:16+00:00

[ Upstream commit ebd77feb27e91bb5fe35a7818b7c13ea7435fb98 ]

correct usage prototype of callback in tasklet_init().
Report by https://github.com/KSPP/linux/issues/20

Signed-off-by: Phong Tran 
Reviewed-by: Kees Cook 
Signed-off-by: Kalle Valo 
Signed-off-by: Sasha Levin

iwlwifi: mvm: fix TDLS discovery with the new firmware API

2020-02-14T21:52:58+00:00

commit b5b878e36c1836c0195575132cc7c199e5a34a7b upstream.

I changed the API for asking for a session protection but
I omitted the TDLS flows. Fix that now.
Note that for the TDLS flow, we need to block until the
session protection actually starts, so add this option
to iwl_mvm_schedule_session_protection.
This patch fixes a firmware assert in the TDLS flow since
the old TIME_EVENT_CMD is not supported anymore by newer
firwmare versions.

Signed-off-by: Emmanuel Grumbach 
Fixes: fe959c7b2049 ("iwlwifi: mvm: use the new session protection command")
Signed-off-by: Luca Coelho 
Signed-off-by: Kalle Valo 
Signed-off-by: Greg Kroah-Hartman

iwlwifi: mvm: avoid use after free for pmsr request

2020-02-14T21:52:58+00:00

commit cc4255eff523f25187bb95561642941de0e57497 upstream.

When a FTM request is aborted, the driver sends the abort command to
the fw and waits for a response. When the response arrives, the driver
calls cfg80211_pmsr_complete() for that request.
However, cfg80211 frees the requested data immediately after sending
the abort command, so this may lead to use after free.

Fix it by clearing the request data in the driver when the abort
command arrives and ignoring the fw notification that will come
afterwards.

Signed-off-by: Avraham Stern 
Fixes: fc36ffda3267 ("iwlwifi: mvm: support FTM initiator")
Signed-off-by: Luca Coelho 
Signed-off-by: Kalle Valo 
Signed-off-by: Greg Kroah-Hartman

iwlwifi: don't throw error when trying to remove IGTK

2020-02-11T12:37:04+00:00

commit 197288d5ba8a5289f22d3aeb4fca3824bfd9b4af upstream.

The IGTK keys are only removed by mac80211 after it has already
removed the AP station.  This causes the driver to throw an error
because mac80211 is trying to remove the IGTK when the station doesn't
exist anymore.

The firmware is aware that the station has been removed and can deal
with it the next time we try to add an IGTK for a station, so we
shouldn't try to remove the key if the station ID is
IWL_MVM_INVALID_STA.  Do this by removing the check for mvm_sta before
calling iwl_mvm_send_sta_igtk() and check return from that function
gracefully if the station ID is invalid.

Cc: stable@vger.kernel.org # 4.12+
Signed-off-by: Luca Coelho 
Signed-off-by: Kalle Valo 
Signed-off-by: Greg Kroah-Hartman

Merge tag 'wireless-drivers-2020-01-23' of git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers

2020-01-23T13:30:20+00:00

Kalle Valo says:

====================
wireless-drivers fixes for v5.5

Second set of fixes for v5.5. There are quite a few patches,
especially on iwlwifi, due to me being on a long break. Libertas also
has a security fix and mt76 a build fix.

iwlwifi

* don't send the PPAG command when PPAG is disabled, since it can cause problems

* a few fixes for a HW bug

* a fix for RS offload;

* a fix for 3168 devices where the NVM tables where the wrong tables were being read

* fix a couple of potential memory leaks in TXQ code

* disable L0S states in all hardware since our hardware doesn't
 officially support them anymore (and older versions of the hardware
 had instability in these states)

* remove lar_disable parameter since it has been causing issues for
  some people who erroneously disable it

* force the debug monitor HW to stop also when debug is disabled,
  since it sometimes stays on and prevents low system power states

* don't send IWL_MVM_RXQ_NSSN_SYNC notification due to DMA problems

libertas

* fix two buffer overflows

mt76

* build fix related to CONFIG_MT76_LEDS

* fix off by one in bitrates handling
====================

Signed-off-by: David S. Miller

net: Fix packet reordering caused by GRO and listified RX cooperation

2020-01-22T19:36:37+00:00

Commit 323ebb61e32b ("net: use listified RX for handling GRO_NORMAL
skbs") introduces batching of GRO_NORMAL packets in napi_frags_finish,
and commit 6570bc79c0df ("net: core: use listified Rx for GRO_NORMAL in
napi_gro_receive()") adds the same to napi_skb_finish. However,
dev_gro_receive (that is called just before napi_{frags,skb}_finish) can
also pass skbs to the networking stack: e.g., when the GRO session is
flushed, napi_gro_complete is called, which passes pp directly to
netif_receive_skb_internal, skipping napi->rx_list. It means that the
packet stored in pp will be handled by the stack earlier than the
packets that arrived before, but are still waiting in napi->rx_list. It
leads to TCP reorderings that can be observed in the TCPOFOQueue counter
in netstat.

This commit fixes the reordering issue by making napi_gro_complete also
use napi->rx_list, so that all packets going through GRO will keep their
order. In order to keep napi_gro_flush working properly, gro_normal_list
calls are moved after the flush to clear napi->rx_list.

iwlwifi calls napi_gro_flush directly and does the same thing that is
done by gro_normal_list, so the same change is applied there:
napi_gro_flush is moved to be before the flush of napi->rx_list.

A few other drivers also use napi_gro_flush (brocade/bna/bnad.c,
cortina/gemini.c, hisilicon/hns3/hns3_enet.c). The first two also use
napi_complete_done afterwards, which performs the gro_normal_list flush,
so they are fine. The latter calls napi_gro_receive right after
napi_gro_flush, so it can end up with non-empty napi->rx_list anyway.

Fixes: 323ebb61e32b ("net: use listified RX for handling GRO_NORMAL skbs")
Signed-off-by: Maxim Mikityanskiy 
Cc: Alexander Lobakin 
Cc: Edward Cree 
Acked-by: Alexander Lobakin 
Acked-by: Saeed Mahameed 
Acked-by: Edward Cree 
Signed-off-by: David S. Miller