<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-stable.git/net/wireless/scan.c, branch v6.4</title>
<subtitle>Linux kernel stable tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/'/>
<entry>
<title>wifi: cfg80211: Drop entries with invalid BSSIDs in RNR</title>
<updated>2023-05-16T17:09:50+00:00</updated>
<author>
<name>Ilan Peer</name>
<email>ilan.peer@intel.com</email>
</author>
<published>2023-04-24T07:32:24+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=1b6b4ed01493b7ea2205ab83c49198f7d13ca9d2'/>
<id>1b6b4ed01493b7ea2205ab83c49198f7d13ca9d2</id>
<content type='text'>
Ignore AP information for entries that include an invalid
BSSID in the TBTT information field, e.g., all zeros BSSIDs.

Fixes: c8cb5b854b40 ("nl80211/cfg80211: support 6 GHz scanning")
Signed-off-by: Ilan Peer &lt;ilan.peer@intel.com&gt;
Signed-off-by: Gregory Greenman &lt;gregory.greenman@intel.com&gt;
Link: https://lore.kernel.org/r/20230424103224.5e65d04d1448.Ic10c8577ae4a85272c407106c9d0a2ecb5372743@changeid
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Ignore AP information for entries that include an invalid
BSSID in the TBTT information field, e.g., all zeros BSSIDs.

Fixes: c8cb5b854b40 ("nl80211/cfg80211: support 6 GHz scanning")
Signed-off-by: Ilan Peer &lt;ilan.peer@intel.com&gt;
Signed-off-by: Gregory Greenman &lt;gregory.greenman@intel.com&gt;
Link: https://lore.kernel.org/r/20230424103224.5e65d04d1448.Ic10c8577ae4a85272c407106c9d0a2ecb5372743@changeid
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>wifi: wireless: cleanup unused function parameters</title>
<updated>2023-03-07T09:47:28+00:00</updated>
<author>
<name>Mordechay Goodstein</name>
<email>mordechay.goodstein@intel.com</email>
</author>
<published>2023-03-01T10:09:20+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=6ff9efcfc2dc256480b252321818e0111b9399a2'/>
<id>6ff9efcfc2dc256480b252321818e0111b9399a2</id>
<content type='text'>
In the past ftype was used for deciding about 6G DUP beacon, but the
logic was removed and ftype is not needed anymore.

Signed-off-by: Mordechay Goodstein &lt;mordechay.goodstein@intel.com&gt;
Signed-off-by: Gregory Greenman &lt;gregory.greenman@intel.com&gt;
Link: https://lore.kernel.org/r/20230301115906.98d4761b809b.I255f5ecd77cb24fcf2f1641bb5833ea2d121296e@changeid
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
In the past ftype was used for deciding about 6G DUP beacon, but the
logic was removed and ftype is not needed anymore.

Signed-off-by: Mordechay Goodstein &lt;mordechay.goodstein@intel.com&gt;
Signed-off-by: Gregory Greenman &lt;gregory.greenman@intel.com&gt;
Link: https://lore.kernel.org/r/20230301115906.98d4761b809b.I255f5ecd77cb24fcf2f1641bb5833ea2d121296e@changeid
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>wifi: wireless: correct primary channel validation on 6 GHz</title>
<updated>2023-03-07T09:46:38+00:00</updated>
<author>
<name>Mordechay Goodstein</name>
<email>mordechay.goodstein@intel.com</email>
</author>
<published>2023-03-01T10:09:19+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=fb4b441c5d764813370e381310d9f82b38e7cd3f'/>
<id>fb4b441c5d764813370e381310d9f82b38e7cd3f</id>
<content type='text'>
The check that beacon primary channel is in the range of 80 MHz
(abs &lt; 80) is invalid for 320 MHz since duplicate beacon transmit
means that the AP transmits it on all the 20 MHz sub-channels:

  9.4.2.249 HE Operation element - ... AP transmits Beacon frames in
  non-HT duplicate PPDU with a TXVECTOR parameter CH_BANDWIDTH value
  that is up to the BSS bandwidth.

So in case of 320 MHz the DUP beacon can be in upper 160 for primary
channel in the lower 160 giving possibly an absolute range of over
80 MHz.

Also this check is redundant alltogether, if AP has a wrong primary
channel in the beacon it's a faulty AP, and we would fail in next
steps to connect.

While at it, fix the frequency comparison to no longer compare
between KHz and MHz, which was introduced by commit 7f599aeccbd2
("cfg80211: Use the HE operation IE to determine a 6GHz BSS channel").

Signed-off-by: Mordechay Goodstein &lt;mordechay.goodstein@intel.com&gt;
Signed-off-by: Gregory Greenman &lt;gregory.greenman@intel.com&gt;
Link: https://lore.kernel.org/r/20230301115906.314faf725255.I5e27251ac558297553b590d3917a7b6d1aae0e74@changeid
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The check that beacon primary channel is in the range of 80 MHz
(abs &lt; 80) is invalid for 320 MHz since duplicate beacon transmit
means that the AP transmits it on all the 20 MHz sub-channels:

  9.4.2.249 HE Operation element - ... AP transmits Beacon frames in
  non-HT duplicate PPDU with a TXVECTOR parameter CH_BANDWIDTH value
  that is up to the BSS bandwidth.

So in case of 320 MHz the DUP beacon can be in upper 160 for primary
channel in the lower 160 giving possibly an absolute range of over
80 MHz.

Also this check is redundant alltogether, if AP has a wrong primary
channel in the beacon it's a faulty AP, and we would fail in next
steps to connect.

While at it, fix the frequency comparison to no longer compare
between KHz and MHz, which was introduced by commit 7f599aeccbd2
("cfg80211: Use the HE operation IE to determine a 6GHz BSS channel").

Signed-off-by: Mordechay Goodstein &lt;mordechay.goodstein@intel.com&gt;
Signed-off-by: Gregory Greenman &lt;gregory.greenman@intel.com&gt;
Link: https://lore.kernel.org/r/20230301115906.314faf725255.I5e27251ac558297553b590d3917a7b6d1aae0e74@changeid
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>wifi: wireless: return primary channel regardless of DUP</title>
<updated>2023-03-07T09:32:44+00:00</updated>
<author>
<name>Mordechay Goodstein</name>
<email>mordechay.goodstein@intel.com</email>
</author>
<published>2023-03-01T10:09:18+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=724a486cd24581928f4a82619806939119304645'/>
<id>724a486cd24581928f4a82619806939119304645</id>
<content type='text'>
Currently in case DUP bit is not set we don't return the primary
channel for 6 GHz Band, but the spec says that the DUP bit has
no effect on this field:

9.4.2.249 HE Operation element:
The Duplicate Beacon subfield is set to 1 if the AP transmits
Beacon frames in non-HT duplicate PPDU with a TXVECTOR parameter
CH_BANDWIDTH value that is up to the BSS bandwidth and is set to
0 otherwise.

So remove the condition for returning primary channel based on DUP.

Since the caller code already marks the signal as invalid in case
the indicated frequency is not the tuned frequency, there's no need
to additionally handle this case here since that's already true for
duplicated beacons on the non-primary channel(s).

Signed-off-by: Mordechay Goodstein &lt;mordechay.goodstein@intel.com&gt;
Signed-off-by: Gregory Greenman &lt;gregory.greenman@intel.com&gt;
Link: https://lore.kernel.org/r/20230301115906.66d7f05f7d11.I5e0add054f72ede95611391b99804c61c40cc959@changeid
[clarify commit message]
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Currently in case DUP bit is not set we don't return the primary
channel for 6 GHz Band, but the spec says that the DUP bit has
no effect on this field:

9.4.2.249 HE Operation element:
The Duplicate Beacon subfield is set to 1 if the AP transmits
Beacon frames in non-HT duplicate PPDU with a TXVECTOR parameter
CH_BANDWIDTH value that is up to the BSS bandwidth and is set to
0 otherwise.

So remove the condition for returning primary channel based on DUP.

Since the caller code already marks the signal as invalid in case
the indicated frequency is not the tuned frequency, there's no need
to additionally handle this case here since that's already true for
duplicated beacons on the non-primary channel(s).

Signed-off-by: Mordechay Goodstein &lt;mordechay.goodstein@intel.com&gt;
Signed-off-by: Gregory Greenman &lt;gregory.greenman@intel.com&gt;
Link: https://lore.kernel.org/r/20230301115906.66d7f05f7d11.I5e0add054f72ede95611391b99804c61c40cc959@changeid
[clarify commit message]
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge tag 'wireless-next-2022-12-02' of git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next</title>
<updated>2022-12-03T04:33:30+00:00</updated>
<author>
<name>Jakub Kicinski</name>
<email>kuba@kernel.org</email>
</author>
<published>2022-12-03T04:33:29+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=edd4e25a230dc8a977fca667db788424917ca2f3'/>
<id>edd4e25a230dc8a977fca667db788424917ca2f3</id>
<content type='text'>
Kalle Valo says:

====================
wireless-next patches for v6.2

Third set of patches for v6.2. mt76 has a new driver for mt7996 Wi-Fi 7
devices and iwlwifi also got initial Wi-Fi 7 support. Otherwise
smaller features and fixes.

Major changes:

ath10k
 - store WLAN firmware version in SMEM image table

mt76
 - mt7996: new driver for MediaTek Wi-Fi 7 (802.11be) devices
 - mt7986, mt7915: enable Wireless Ethernet Dispatch (WED) offload support
 - mt7915: add ack signal support
 - mt7915: enable coredump support
 - mt7921: remain_on_channel support
 - mt7921: channel context support

iwlwifi
 - enable Wi-Fi 7 Extremely High Throughput (EHT) PHY capabilities
 - 320 MHz channels support

* tag 'wireless-next-2022-12-02' of git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next: (144 commits)
  wifi: ath10k: fix QCOM_SMEM dependency
  wifi: mt76: mt7921e: add pci .shutdown() support
  wifi: mt76: mt7915: mmio: fix naming convention
  wifi: mt76: mt7996: add support to configure spatial reuse parameter set
  wifi: mt76: mt7996: enable ack signal support
  wifi: mt76: mt7996: enable use_cts_prot support
  wifi: mt76: mt7915: rely on band_idx of mt76_phy
  wifi: mt76: mt7915: enable per bandwidth power limit support
  wifi: mt76: mt7915: introduce mt7915_get_power_bound()
  mt76: mt7915: Fix PCI device refcount leak in mt7915_pci_init_hif2()
  wifi: mt76: do not send firmware FW_FEATURE_NON_DL region
  wifi: mt76: mt7921: Add missing __packed annotation of struct mt7921_clc
  wifi: mt76: fix coverity overrun-call in mt76_get_txpower()
  wifi: mt76: mt7996: add driver for MediaTek Wi-Fi 7 (802.11be) devices
  wifi: mt76: mt76x0: remove dead code in mt76x0_phy_get_target_power
  wifi: mt76: mt7915: fix band_idx usage
  wifi: mt76: mt7915: enable .sta_set_txpwr support
  wifi: mt76: mt7915: add basedband Txpower info into debugfs
  wifi: mt76: mt7915: add support to configure spatial reuse parameter set
  wifi: mt76: mt7915: add missing MODULE_PARM_DESC
  ...
====================

Link: https://lore.kernel.org/r/20221202214254.D0D3DC433C1@smtp.kernel.org
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Kalle Valo says:

====================
wireless-next patches for v6.2

Third set of patches for v6.2. mt76 has a new driver for mt7996 Wi-Fi 7
devices and iwlwifi also got initial Wi-Fi 7 support. Otherwise
smaller features and fixes.

Major changes:

ath10k
 - store WLAN firmware version in SMEM image table

mt76
 - mt7996: new driver for MediaTek Wi-Fi 7 (802.11be) devices
 - mt7986, mt7915: enable Wireless Ethernet Dispatch (WED) offload support
 - mt7915: add ack signal support
 - mt7915: enable coredump support
 - mt7921: remain_on_channel support
 - mt7921: channel context support

iwlwifi
 - enable Wi-Fi 7 Extremely High Throughput (EHT) PHY capabilities
 - 320 MHz channels support

* tag 'wireless-next-2022-12-02' of git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next: (144 commits)
  wifi: ath10k: fix QCOM_SMEM dependency
  wifi: mt76: mt7921e: add pci .shutdown() support
  wifi: mt76: mt7915: mmio: fix naming convention
  wifi: mt76: mt7996: add support to configure spatial reuse parameter set
  wifi: mt76: mt7996: enable ack signal support
  wifi: mt76: mt7996: enable use_cts_prot support
  wifi: mt76: mt7915: rely on band_idx of mt76_phy
  wifi: mt76: mt7915: enable per bandwidth power limit support
  wifi: mt76: mt7915: introduce mt7915_get_power_bound()
  mt76: mt7915: Fix PCI device refcount leak in mt7915_pci_init_hif2()
  wifi: mt76: do not send firmware FW_FEATURE_NON_DL region
  wifi: mt76: mt7921: Add missing __packed annotation of struct mt7921_clc
  wifi: mt76: fix coverity overrun-call in mt76_get_txpower()
  wifi: mt76: mt7996: add driver for MediaTek Wi-Fi 7 (802.11be) devices
  wifi: mt76: mt76x0: remove dead code in mt76x0_phy_get_target_power
  wifi: mt76: mt7915: fix band_idx usage
  wifi: mt76: mt7915: enable .sta_set_txpwr support
  wifi: mt76: mt7915: add basedband Txpower info into debugfs
  wifi: mt76: mt7915: add support to configure spatial reuse parameter set
  wifi: mt76: mt7915: add missing MODULE_PARM_DESC
  ...
====================

Link: https://lore.kernel.org/r/20221202214254.D0D3DC433C1@smtp.kernel.org
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>wifi: cfg80211: use bss_from_pub() instead of container_of()</title>
<updated>2022-12-01T14:09:10+00:00</updated>
<author>
<name>Johannes Berg</name>
<email>johannes.berg@intel.com</email>
</author>
<published>2022-10-17T07:03:48+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=61e41e5dfcc22e5e65b6537453fd2f03ac768b82'/>
<id>61e41e5dfcc22e5e65b6537453fd2f03ac768b82</id>
<content type='text'>
There's no need to open-code container_of() when we have
bss_from_pub(). Use it.

Change-Id: I074723717909ba211a40e6499f0c36df0e2ba4be
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
There's no need to open-code container_of() when we have
bss_from_pub(). Use it.

Change-Id: I074723717909ba211a40e6499f0c36df0e2ba4be
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>wifi: cfg80211: fix comparison of BSS frequencies</title>
<updated>2022-12-01T14:09:09+00:00</updated>
<author>
<name>JUN-KYU SHIN</name>
<email>jk.shin@newratek.com</email>
</author>
<published>2022-11-11T02:33:04+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=c1d3214d61d93eb4a3959c6b402230988d0f362d'/>
<id>c1d3214d61d93eb4a3959c6b402230988d0f362d</id>
<content type='text'>
If the "channel-&gt;freq_offset" comparison is omitted in cmp_bss(),
BSS with different kHz units cannot be distinguished in the S1G Band.
So "freq_offset" should also be included in the comparison.

Signed-off-by: JUN-KYU SHIN &lt;jk.shin@newratek.com&gt;
Link: https://lore.kernel.org/r/20221111023301.6395-1-jk.shin@newratek.com
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
If the "channel-&gt;freq_offset" comparison is omitted in cmp_bss(),
BSS with different kHz units cannot be distinguished in the S1G Band.
So "freq_offset" should also be included in the comparison.

Signed-off-by: JUN-KYU SHIN &lt;jk.shin@newratek.com&gt;
Link: https://lore.kernel.org/r/20221111023301.6395-1-jk.shin@newratek.com
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net</title>
<updated>2022-11-29T21:04:52+00:00</updated>
<author>
<name>Jakub Kicinski</name>
<email>kuba@kernel.org</email>
</author>
<published>2022-11-29T21:04:52+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=f2bb566f5c977ff010baaa9e5e14d9a75b06e5f2'/>
<id>f2bb566f5c977ff010baaa9e5e14d9a75b06e5f2</id>
<content type='text'>
tools/lib/bpf/ringbuf.c
  927cbb478adf ("libbpf: Handle size overflow for ringbuf mmap")
  b486d19a0ab0 ("libbpf: checkpatch: Fixed code alignments in ringbuf.c")
https://lore.kernel.org/all/20221121122707.44d1446a@canb.auug.org.au/

Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
tools/lib/bpf/ringbuf.c
  927cbb478adf ("libbpf: Handle size overflow for ringbuf mmap")
  b486d19a0ab0 ("libbpf: checkpatch: Fixed code alignments in ringbuf.c")
https://lore.kernel.org/all/20221121122707.44d1446a@canb.auug.org.au/

Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>wifi: cfg80211: don't allow multi-BSSID in S1G</title>
<updated>2022-11-25T11:43:14+00:00</updated>
<author>
<name>Johannes Berg</name>
<email>johannes.berg@intel.com</email>
</author>
<published>2022-11-25T11:36:58+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=acd3c92acc7aaec50a94d0a7faf7ccd74e952493'/>
<id>acd3c92acc7aaec50a94d0a7faf7ccd74e952493</id>
<content type='text'>
In S1G beacon frames there shouldn't be multi-BSSID elements
since that's not supported, remove that to avoid a potential
integer underflow and/or misparsing the frames due to the
different length of the fixed part of the frame.

While at it, initialize non_tx_data so we don't send garbage
values to the user (even if it doesn't seem to matter now.)

Reported-and-tested-by: Sönke Huster &lt;shuster@seemoo.tu-darmstadt.de&gt;
Fixes: 9eaffe5078ca ("cfg80211: convert S1G beacon to scan results")
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
In S1G beacon frames there shouldn't be multi-BSSID elements
since that's not supported, remove that to avoid a potential
integer underflow and/or misparsing the frames due to the
different length of the fixed part of the frame.

While at it, initialize non_tx_data so we don't send garbage
values to the user (even if it doesn't seem to matter now.)

Reported-and-tested-by: Sönke Huster &lt;shuster@seemoo.tu-darmstadt.de&gt;
Fixes: 9eaffe5078ca ("cfg80211: convert S1G beacon to scan results")
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>wifi: cfg80211: fix buffer overflow in elem comparison</title>
<updated>2022-11-25T11:43:05+00:00</updated>
<author>
<name>Johannes Berg</name>
<email>johannes.berg@intel.com</email>
</author>
<published>2022-11-25T11:36:57+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=9f16b5c82a025cd4c864737409234ddc44fb166a'/>
<id>9f16b5c82a025cd4c864737409234ddc44fb166a</id>
<content type='text'>
For vendor elements, the code here assumes that 5 octets
are present without checking. Since the element itself is
already checked to fit, we only need to check the length.

Reported-and-tested-by: Sönke Huster &lt;shuster@seemoo.tu-darmstadt.de&gt;
Fixes: 0b8fb8235be8 ("cfg80211: Parsing of Multiple BSSID information in scanning")
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
For vendor elements, the code here assumes that 5 octets
are present without checking. Since the element itself is
already checked to fit, we only need to check the length.

Reported-and-tested-by: Sönke Huster &lt;shuster@seemoo.tu-darmstadt.de&gt;
Fixes: 0b8fb8235be8 ("cfg80211: Parsing of Multiple BSSID information in scanning")
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</pre>
</div>
</content>
</entry>
</feed>
