| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
If we do get multiple notifications from firmware, then
we might have allocated 'notif', but don't free it. Fix
that by checking for duplicates before allocation.
Fixes: 4da46a06d443 ("wifi: iwlwifi: mvm: Add support for wowlan info notification")
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://lore.kernel.org/r/20230418122405.116758321cc4.I8bdbcbb38c89ac637eaa20dda58fa9165b25893a@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
We should pass the newly allocated data to fill.
Signed-off-by: Alon Giladi <alon.giladi@intel.com>
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://lore.kernel.org/r/20230418122405.aaa6d8874442.I734841c71aad9564cb22c50f2737aaff489fadaf@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
The RADA/firmware collaborate on MIC stripping in the following
way:
- the firmware fills the IWL_RX_MPDU_MFLG1_MIC_CRC_LEN_MASK
value for how many words need to be removed at the end of
the frame, CRC and, if decryption was done, MIC
- if the RADA is active, it will
- remove that much from the end of the frame
- zero the value in IWL_RX_MPDU_MFLG1_MIC_CRC_LEN_MASK
As a consequence, the only thing the driver should need to do
is to
- unconditionally tell mac80211 that the MIC was removed
if decryption was already done
- remove as much as IWL_RX_MPDU_MFLG1_MIC_CRC_LEN_MASK says
at the end of the frame, since either RADA did it and then
the value is 0, or RADA was disabled and then the value is
whatever should be removed to strip both CRC & MIC
However, all this code was historically grown and getting a
bit confused. Originally, we were indicating that the MIC was
not stripped, which is the version of the code upstreamed in
commit 780e87c29e77 ("iwlwifi: mvm: add 9000 series RX processing")
which indicated RX_FLAG_DECRYPTED in iwl_mvm_rx_crypto().
We later had a commit to change that to also indicate that the
MIC was stripped, adding RX_FLAG_MIC_STRIPPED. However, this was
then "fixed" later to only do that conditionally on RADA being
enabled, since otherwise RADA didn't strip the MIC bytes yet.
At the time, we were also always including the FCS if the RADA
was not enabled, so that was still broken wrt. the FCS if the
RADA isn't enabled - but that's a pretty rare case. Notably
though, it does happen for management frames, where we do need
to remove the MIC and CRC but the RADA is disabled.
Later, in commit 40a0b38d7a7f ("iwlwifi: mvm: Fix calculation of
frame length"), we changed this again, upstream this was just a
single commit, but internally it was split into first the correct
commit and then an additional fix that reduced the number of bytes
that are removed by crypt_len. Note that this is clearly wrong
since crypt_len indicates the length of the PN header (always 8),
not the length of the MIC (8 or 16 depending on algorithm).
However, this additional fix mostly canceled the other bugs,
apart from the confusion about the size of the MIC.
To fix this correctly, remove all those additional workarounds.
We really should always indicate to mac80211 the MIC was stripped
(it cannot use it anyway if decryption was already done), and also
always actually remove it and the CRC regardless of the RADA being
enabled or not. That's simple though, the value indicated in the
metadata is zeroed by the RADA if it's enabled and used the value,
so there's no need to check if it's enabled or not.
Notably then, this fixes the MIC size confusion, letting us receive
GCMP-256 encrypted management frames correctly that would otherwise
be reported to mac80211 8 bytes too short since the RADA is turned
off for them, crypt_len is 8, but the MIC size is 16, so when we do
the adjustment based on IWL_RX_MPDU_MFLG1_MIC_CRC_LEN_MASK (which
indicates 20 bytes to remove) we remove 12 bytes but indicate then
to mac80211 the MIC is still present, so mac80211 again removes the
MIC of 16 bytes, for an overall removal of 28 rather than 20 bytes.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://lore.kernel.org/r/20230418122405.81345b6ab0cd.Ibe0348defb6cce11c99929a1f049e60b5cfc150c@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
Fix a memory leak that occurs when reading the fw_info
file all the way, since we return NULL indicating no
more data, but don't free the status tracking object.
Fixes: 36dfe9ac6e8b ("iwlwifi: dump api version in yaml format")
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://lore.kernel.org/r/20230418122405.239e501b3b8d.I4268f87809ef91209cbcd748eee0863195e70fa2@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
Add support for B0 version of MAC of MR device
Signed-off-by: Mukesh Sisodiya <mukesh.sisodiya@intel.com>
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://lore.kernel.org/r/20230418122405.5dca1ea7a0cf.I87932e1e216a1940eeae8824071ecb777f4c034f@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
A received TKIP key may be up to 32 bytes because it may contain
MIC rx/tx keys too. These are not used by iwl and copying these
over overflows the iwl_keyinfo.key field.
Add a check to not copy more data to iwl_keyinfo.key then will fit.
This fixes backtraces like this one:
memcpy: detected field-spanning write (size 32) of single field "sta_cmd.key.key" at drivers/net/wireless/intel/iwlwifi/dvm/sta.c:1103 (size 16)
WARNING: CPU: 1 PID: 946 at drivers/net/wireless/intel/iwlwifi/dvm/sta.c:1103 iwlagn_send_sta_key+0x375/0x390 [iwldvm]
<snip>
Hardware name: Dell Inc. Latitude E6430/0H3MT5, BIOS A21 05/08/2017
RIP: 0010:iwlagn_send_sta_key+0x375/0x390 [iwldvm]
<snip>
Call Trace:
<TASK>
iwl_set_dynamic_key+0x1f0/0x220 [iwldvm]
iwlagn_mac_set_key+0x1e4/0x280 [iwldvm]
drv_set_key+0xa4/0x1b0 [mac80211]
ieee80211_key_enable_hw_accel+0xa8/0x2d0 [mac80211]
ieee80211_key_replace+0x22d/0x8e0 [mac80211]
<snip>
Link: https://www.alionet.org/index.php?topic=1469.0
Link: https://lore.kernel.org/linux-wireless/20230218191056.never.374-kees@kernel.org/
Link: https://lore.kernel.org/linux-wireless/68760035-7f75-1b23-e355-bfb758a87d83@redhat.com/
Cc: Kees Cook <keescook@chromium.org>
Suggested-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
Start supporting API version 78 for AX devices.
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://lore.kernel.org/r/20230417113648.5a4dcbf5a2c1.I125808566fe892ee0865e392bf1b1872daafe8ad@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
Check the firmware response size for responses to the
memory read/write command in debugfs before using it.
Fixes: 2b55f43f8e47 ("iwlwifi: mvm: Add mem debugfs entry")
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://lore.kernel.org/r/20230417113648.0d56fcaf68ee.I70e9571f3ed7263929b04f8fabad23c9b999e4ea@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
For MLO support, use the pointer to the peer MLD instead of the default
link station id, since the default link is only used for non-MLO cases.
Using the default link sta id is meaningless for MLO. Also remove the
rcu protected section since we now avoid the lookup based on sta id.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://lore.kernel.org/r/20230417113648.40cef48c0592.I8dd666d603d6e1854033e5369c70e78d9303d236@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
If the AP station already exists on link activation (which
means we're during link switch), configure the TLC in FW so
we can immediately transmit once the link is activated.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://lore.kernel.org/r/20230417113648.1a93de9b7c1f.I42022f24bbe3572f5a082da8c99794ae14281875@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
For MLO, we cannot use vif->bss_conf.chandef.chan->band, since
that will lead to a NULL-ptr dereference as bss_conf isn't used.
However, in case of real MLO, we also need to take both LMACs
into account if they exist, since the station might be active
on both LMACs at the same time.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://lore.kernel.org/r/20230417113648.3588afc85d79.I11592893bbc191b9548518b8bd782de568a9f848@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
Track instead whether or not the station was authorized, that's
clearer than trying to indicate in the code whether or not the
full bandwidth should be used via an 'update' argument.
While at it, give rs_fw_rate_init() the iwl_mvm_ prefix.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://lore.kernel.org/r/20230417113648.92bd8d36e311.I1877a109104d5ffeaaad6a623e89f0c44decc38e@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
When allocating a new link station, initialize the ratescaling
data for it. To do that, refactor the initialization code out
into a new iwl_mvm_rs_add_sta_link() function.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://lore.kernel.org/r/20230417113648.441b6a8c60fd.I34f1b3555c25aaa22cc34d1112fc3b6393a20b7c@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
We need to look up the correct version of this struct depending
on the interface type, rather than just checking if the pointer
is non-NULL. Fix that.
Fixes: befebbb30af0 ("iwlwifi: rs: consider LDPC capability in case of HE")
Fixes: b009cf71a982 ("iwlwifi: mvm: only enable HE DCM if we also support TX")
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://lore.kernel.org/r/20230417113648.1fd54368a02c.Ie4db5e8ae224d9a4a63b528da5d63e1b957b9cef@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
Since only clients to an AP can be 20MHz-only STAs, adjust the
code to not make the use of EHT capabilities depend on only the
bandwidth, but also the type of interface.
Fixes: 701404f1091d ("wifi: iwlwifi: rs: add support for parsing max MCS per NSS/BW in 11be")
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://lore.kernel.org/r/20230417113648.a3a4c931e4a3.I693a07f4d88044c889eee04793883a83bc5ee362@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
When this is called it might crash due to the use of
deflink's phy context, update all links instead. It
really shouldn't be called right now though, but it's
better to have safer code until we update this to be
with a link parameter.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://lore.kernel.org/r/20230417113648.fd47d0de8319.I87c5e5bcb2fadd70acc32021eed394fc1eea12a4@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
When we first add the STA before sending an authentication
frame this is false. However, in some cases such as FT or
certainly in MLO link switch scenarios, it will be true.
If it happens to be true, it causes a firmware assert (in
LMAC, 0x2528), because the same bit is used by the firmware
for tracking this setting as well as for tracking if the
management key has been installed, and then we get this
assert from the firmware when installing the MFP key as it
thinks it has already been installed.
Remove the setting for now, until the firmware disentangles
the two. We should be able to set it, in fact we should be
setting it speculatively before authentication/association,
to avoid processing management frames that should have been
protected/encrypted before the key is set.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://lore.kernel.org/r/20230417113648.adbeb0e0bfed.I400d0ee3721dc4f294313be992d277ba4d9c88d9@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
We can allow NL80211_EXT_FEATURE_SCAN_MIN_PREQ_CONTENT since we
just use the elements from mac80211.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://lore.kernel.org/r/20230417113648.88b1a70365fd.If5030437707ab67e2146291c1517a9b0e31d01ab@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
A long time, ago in commit 818965d39177 ("cfg80211: Allow a
scan request for a specific BSSID"), the stack started passing
the BSSID that should be scanned for. Use it in iwlwifi for the
intended optimisation, and to also allow the use of this for an
implementation sending multi-link probe requests.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://lore.kernel.org/r/20230417113648.0be90360cad7.If279c28079a1db34280a824cee7c3f6545fd8b9e@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
The restriction where MAC ID 0 could be used only for the
managed/IBSS vif is not required when using the new MLO FW API.
Update the driver.
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://lore.kernel.org/r/20230417113648.e4355615da92.Iba934ccf8589c3c27a25a390dc5e938312889b45@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
The firmware no longer wants the beacon template inside the MAC command.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://lore.kernel.org/r/20230417113648.92aed4180a06.I277efa343c88081cb3fc890dcbeae3161cdffe16@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
This is noising the kernel log and customers asked to hush it down.
We can live with this message in "info" verbosity.
Signed-off-by: Golan Ben Ami <golan.ben.ami@intel.com>
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://lore.kernel.org/r/20230416154301.0a7f557aa2a0.If9db474b63242b1bfaed659aa174b678ae8dc196@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
Since we didn't reset t to 0, only the first iteration of the loop
did checked the ready bit several times.
From the second iteration and on, we just tested the bit once and
continued to the next iteration.
Reported-and-tested-by: Lorenzo Zolfanelli <lorenzo@zolfa.nl>
Link: https://bugzilla.kernel.org/show_bug.cgi?id=216452
Fixes: 289e5501c314 ("iwlwifi: fix the preparation of the card")
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://lore.kernel.org/r/20230416154301.615b683ab9c8.Ic52c3229d3345b0064fa34263293db095d88daf8@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
Newer firmware images have a TLV advertising how many
beacons they support, use that to permit adding more
links in AP mode (FW needs to support at least as many
links as beacons).
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://lore.kernel.org/r/20230416154301.0d7522533557.Ic6b5992e94446c35cb0f3add019defa6e7aded2a@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
Implement switching keys from one set of firmware station IDs
to another set, during link switch.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://lore.kernel.org/r/20230416154301.c6a777dd5e47.I693f7fd7c52fe8b51a58af69d45488511367f49e@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
When we switch station links, also add the code to switch
BAIDs from one station mask to the new one.
To do so, refactor the switching code a bit to have common
code for all the needed switches; will add keys next.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://lore.kernel.org/r/20230416154301.40654afce24f.I0e35151f69e7513be53ddb8f008e9ab48278c352@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
When we have MLO connections, a BAID applies to multiple
firmware stations. Track the station mask instead of the
station ID, getting rid of a few more deflink cases and
preparing for handling link switching for BAIDs.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://lore.kernel.org/r/20230416154301.c08523808c34.I719b7bba499648d1495ed3e3a90889d4732ef15d@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
Start supporting API version 77 for AX devices.
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://lore.kernel.org/r/20230416154301.e522ccefe354.If7628363fafeb7687163103e734206915c445197@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
When we remove a queue we need to use the currently active
firmware stations in the mask, not the deflink one. Fix that.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://lore.kernel.org/r/20230416154301.01cdd2153418.I176d54f2d869f51b3707d056adb96455cf885f93@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
The initiator smooth list is initialized only in iwl_mvm_up(), but is
cleared in iwl_mvm_mac_stop. This may result in iterating over the
list before it was initialized in case iwl_mvm_up() failed early.
Fix it by moving the list initialization to an earlier stage.
Fixes: b68bd2e3143a ("iwlwifi: mvm: Add FTM initiator RTT smoothing logic")
Signed-off-by: Avraham Stern <avraham.stern@intel.com>
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://lore.kernel.org/r/20230416154301.b50b1fe9a576.Ie348ffae110612d2e252ac120a3ba0aea063b1b6@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
We are going to need this in more places than just the
key code, so factor out the functionality of getting
the FW station ID mask (filtered to a specific link if
needed) to a separate function that can now be called
both under RCU and mvm->mutex protection.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://lore.kernel.org/r/20230416154301.eff92b93025d.I2c50290a0537d5db3d3460f4d57c78a4712ffb75@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
The firmware split the HE support field into HE and "pseudo HE",
the latter is really for AP and doesn't implement trigger frame
handling for example.
Use the new field for AP mode.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://lore.kernel.org/r/20230416154301.34dbfefe2a49.I0e39cd35dbe03ff9209b26733746479eae1c8966@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
The usage of the 'dtim_period' value was wrong, as it is only
a multiplier of the beacon interval, and thus, beacon interval should
also be considered. Fix it.
Signed-off-by: Ilan Peer <ilan.peer@intel.com>
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://lore.kernel.org/r/20230416154301.e08293d6cace.I25f8cea3189472bd714676ca38b121d7c60fb9d9@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
In iwl_mvm_mac_ctxt_get_lowest_rate() we were still accessing
vif->bss_conf without any multi-link provisions, and also the
info->band, both of which isn't valid in MLO.
Fix the code to look at the correct link. In case of EAPOL
transmissions for the initial 4-way-HS, look up the correct
link here as well, and warn if multiple are active.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://lore.kernel.org/r/20230416154301.d892f68d3bcd.I7d6927abeea5c3899db225391dbc6a5c77805e80@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
When rx/tx queues are being freed, on a different CPU there could be
still rx flow running. Call napi_synchronize() to prevent such a race.
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Co-developed-by: Benjamin Berg <benjamin.berg@intel.com>
Signed-off-by: Benjamin Berg <benjamin.berg@intel.com>
Link: https://lore.kernel.org/r/20230416154301.5171ee44dcc1.Iff18718540da412e084e7d8266447d40730600ed@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
For some devices, in client mode, we support full bandwidth
uplink multi-user MIMO. Add the necessary capability.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://lore.kernel.org/r/20230416154301.88b6aac6c876.Ibf2a7a38d7a172c371c347c9d4441e8c656cefe3@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
The if statement here is misleading, we return zero anyway
since we just checked the 'ret' variable, simplify the code
to remove the condition entirely.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://lore.kernel.org/r/20230414130637.57c1eb58e655.I1b47a7771cd66306931089c150c6b5b240bdcba5@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
The setting of the rate used for non station cases did not take into
consideration the interface type etc., thus when probe responses
are transmitted on P2P Device interface etc. CCK rates were used
which is not allowed.
Modify the code so the non station case would consider the
interface type etc. For HWs/FWs that do not support rate control,
preserve the previous behavior, i.e., take the rate from the
skb metadata and adjust as needed.
Signed-off-by: Ilan Peer <ilan.peer@intel.com>
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://lore.kernel.org/r/20230414130637.fa0e4d42205d.Iab4784560c77b965fec070d4d0a1ec84171d94ff@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
If we have MLO, then the deflink.ap_sta_id cannot be used.
However, we can use the new mvmvif->ap_sta pointer for the
validation instead.
Also don't do it multiple times for different FW instances
of the same AP STA (TDLS STAs are only on a single link).
Note that this isn't really working right yet since the
underlying flush code hasn't been updated yet to know of
multiple link STAs.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://lore.kernel.org/r/20230414130637.7d747df44d65.Ie5392859fab4cfb73c20b49bfee2caadef5fd8ec@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
Implement the full STA mask and selecting the correct link
for key installation.
While at it, catch errors if this function returns a bad
zero station mask, rather than waiting for the firmware to
crash on it.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://lore.kernel.org/r/20230414130637.cedae2f21829.Iae07b736c3109d085ad5b74ec8282ce45020da39@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
If adding a key to firmware fails we leak the allocated ptk_pn.
This shouldn't happen in practice, but we should still fix it.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://lore.kernel.org/r/20230414130637.99446ffd02bc.I82a2ad6ec1395f188e0a1677cc619e3fcb1feac9@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
We never needed this to be non-static, that was just an
artifact of the development process. Make it static.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://lore.kernel.org/r/20230414130637.3c018c15f948.I87fd1aee288f33312a7206492608002d4e8e213e@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
Instead of relying on the AP STA ID and dereferencing our
firmware -> mac80211 STA array when we really only need
the STA, not the per-link information (and might not have
it, e.g. for a pairwise key installation where this is
relevant), keep track of the AP STA as a pointer to the
mac80211 STA, protected by the mutex. Then use it here in
the key code instead.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://lore.kernel.org/r/20230414130637.7db01b1508de.I88e6d252cdb0a6e4581d7c5fd7cbc037b4fd40ae@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
An integer overflow occurs in the iwl_write_to_user_buf() function,
which is called by the iwl_dbgfs_monitor_data_read() function.
static bool iwl_write_to_user_buf(char __user *user_buf, ssize_t count,
void *buf, ssize_t *size,
ssize_t *bytes_copied)
{
int buf_size_left = count - *bytes_copied;
buf_size_left = buf_size_left - (buf_size_left % sizeof(u32));
if (*size > buf_size_left)
*size = buf_size_left;
If the user passes a SIZE_MAX value to the "ssize_t count" parameter,
the ssize_t count parameter is assigned to "int buf_size_left".
Then compare "*size" with "buf_size_left" . Here, "buf_size_left" is a
negative number, so "*size" is assigned "buf_size_left" and goes into
the third argument of the copy_to_user function, causing a heap overflow.
This is not a security vulnerability because iwl_dbgfs_monitor_data_read()
is a debugfs operation with 0400 privileges.
Signed-off-by: Hyunwoo Kim <imv4bel@gmail.com>
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://lore.kernel.org/r/20230414130637.2d80ace81532.Iecfba549e0e0be21bbb0324675392e42e75bd5ad@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
Clang static analysis reports this representative issue
dbg.c:1455:6: warning: Branch condition evaluates to
a garbage value
if (!rxf_data.size)
^~~~~~~~~~~~~~
This check depends on iwl_ini_get_rxf_data() to clear
rxf_data but the function can return early without
doing the clear. So move the memset before the early
return.
Fixes: cc9b6012d34b ("iwlwifi: yoyo: use hweight_long instead of bit manipulating")
Signed-off-by: Tom Rix <trix@redhat.com>
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://lore.kernel.org/r/20230414130637.872a7175f1ff.I33802a77a91998276992b088fbe25f61c87c33ac@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
Clang static analysis reports this issue
d3.c:567:22: warning: The left operand of '>' is
a garbage value
if (seq.tkip.iv32 > cur_rx_iv32)
~~~~~~~~~~~~~ ^
seq is never initialized. Call ieee80211_get_key_rx_seq() to
initialize seq.
Fixes: 0419e5e672d6 ("iwlwifi: mvm: d3: separate TKIP data from key iteration")
Signed-off-by: Tom Rix <trix@redhat.com>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://lore.kernel.org/r/20230414130637.6dd372f84f93.If1f708c90e6424a935b4eba3917dfb7582e0dd0a@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
There is a spelling mistake in a IWL_DEBUG_SCAN debug message. Fix it.
Signed-off-by: Colin Ian King <colin.i.king@gmail.com>
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://lore.kernel.org/r/20230414130637.eac55cbef8f1.I15cc5d3f1489759bf915bfb3cbbb72b67b18f8b6@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
There is a spelling mistake in a IWL_ERR error message. Fix it.
Signed-off-by: Colin Ian King <colin.i.king@gmail.com>
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://lore.kernel.org/r/20230414130637.a00965734d02.I760cb43829b3d7a0f567f0958059f2fae0aa8a93@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
Enable the new FW API with MLD based on FW TLV.
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://lore.kernel.org/r/20230414130637.5dc66b08539e.I1c65024c879346b0349e1e431d36ec2b5fd85dd7@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
Add support for a new PCI device ID 0x272b once registering with PCIe.
Signed-off-by: Mukesh Sisodiya <mukesh.sisodiya@intel.com>
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://lore.kernel.org/r/20230414130637.56342664110d.I5aa6f2858fdcf69fdea4f1a873115a48bd43764e@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
