<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/net/mac80211/rx.c, branch v7.0.10</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v7.0.10</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v7.0.10'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2026-05-14T13:31:03+00:00</updated>
<entry>
<title>wifi: mac80211: drop stray 'static' from fast-RX rx_result</title>
<updated>2026-05-14T13:31:03+00:00</updated>
<author>
<name>Catherine</name>
<email>enderaoelyther@gmail.com</email>
</author>
<published>2026-04-24T13:14:36+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=3ef44f96ccc3e06e059dec57842e366f0c4b1893'/>
<id>urn:sha1:3ef44f96ccc3e06e059dec57842e366f0c4b1893</id>
<content type='text'>
commit 7a5b81e0c87a075afd572f659d8eb68c9c4cd2ba upstream.

ieee80211_invoke_fast_rx() is documented as safe for parallel RX, but
its per-invocation rx_result is declared static. Concurrent callers then
share one instance and can overwrite each other's result between
ieee80211_rx_mesh_data() and the switch on res.

That can make a packet that was queued or consumed by
ieee80211_rx_mesh_data() fall through into ieee80211_rx_8023(), or make
a packet that should continue return as queued.

Make res an automatic variable so each invocation keeps its own result.

Fixes: 3468e1e0c639 ("wifi: mac80211: add mesh fast-rx support")
Cc: stable@vger.kernel.org
Signed-off-by: Catherine &lt;enderaoelyther@gmail.com&gt;
Link: https://patch.msgid.link/20260424131435.83212-2-enderaoelyther@gmail.com
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>wifi: mac80211: Add eMLSR/eMLMR action frame parsing support</title>
<updated>2026-02-02T09:11:18+00:00</updated>
<author>
<name>Lorenzo Bianconi</name>
<email>lorenzo@kernel.org</email>
</author>
<published>2026-01-29T13:15:46+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=0d95280a2d54ebd3d38adc4ff67808009798978c'/>
<id>urn:sha1:0d95280a2d54ebd3d38adc4ff67808009798978c</id>
<content type='text'>
Introduce support in AP mode for parsing of the Operating Mode Notification
frame sent by the client to enable/disable MLO eMLSR or eMLMR if supported
by both the AP and the client.
Add drv_set_eml_op_mode mac80211 callback in order to configure underlay
driver with eMLSR/eMLMR info.

Tested-by: Christian Marangi &lt;ansuelsmth@gmail.com&gt;
Signed-off-by: Lorenzo Bianconi &lt;lorenzo@kernel.org&gt;
Link: https://patch.msgid.link/20260129-mac80211-emlsr-v4-1-14bdadf57380@kernel.org
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</content>
</entry>
<entry>
<title>wifi: mac80211: add initial UHR support</title>
<updated>2026-02-02T09:11:08+00:00</updated>
<author>
<name>Johannes Berg</name>
<email>johannes.berg@intel.com</email>
</author>
<published>2026-01-30T15:21:07+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=a1085114715ee9980405d6856276c5e88339cee7'/>
<id>urn:sha1:a1085114715ee9980405d6856276c5e88339cee7</id>
<content type='text'>
Add support for making UHR connections and accepting AP
stations with UHR support.

Link: https://patch.msgid.link/20260130164259.7185980484eb.Ieec940b58dbf8115dab7e1e24cb5513f52c8cb2f@changeid
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</content>
</entry>
<entry>
<title>wifi: mac80211: use u64_stats_t with u64_stats_sync properly</title>
<updated>2026-01-27T12:43:49+00:00</updated>
<author>
<name>David Yang</name>
<email>mmyangfl@gmail.com</email>
</author>
<published>2026-01-23T20:38:40+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=95110e5736d054771c92d14b3b4a13ca6dead519'/>
<id>urn:sha1:95110e5736d054771c92d14b3b4a13ca6dead519</id>
<content type='text'>
On 64bit arches, struct u64_stats_sync is empty and provides no help
against load/store tearing. Convert to u64_stats_t to ensure atomic
operations.

Signed-off-by: David Yang &lt;mmyangfl@gmail.com&gt;
Link: https://patch.msgid.link/20260123203845.2915525-1-mmyangfl@gmail.com
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</content>
</entry>
<entry>
<title>wifi: mac80211: remove RX_DROP</title>
<updated>2026-01-19T09:21:47+00:00</updated>
<author>
<name>Johannes Berg</name>
<email>johannes.berg@intel.com</email>
</author>
<published>2026-01-16T08:20:25+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=58dc87d839280ac0f57b2a5caf647c2ed5cab1aa'/>
<id>urn:sha1:58dc87d839280ac0f57b2a5caf647c2ed5cab1aa</id>
<content type='text'>
Since it's hard to figure out what RX_DROP means when looking
at traces that drop packets in mac80211, add more specific drop
reasons and remove RX_DROP entirely.

Link: https://patch.msgid.link/20260116092025.79d995e87026.I7cde413988f7a382c551cd1c1e2b05a52ec71755@changeid
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</content>
</entry>
<entry>
<title>wifi: mac80211: add support for encryption/decryption of (Re)Association frames</title>
<updated>2026-01-14T13:55:38+00:00</updated>
<author>
<name>Kavita Kavita</name>
<email>kavita.kavita@oss.qualcomm.com</email>
</author>
<published>2026-01-14T11:18:59+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=3d2515fdd336b2c785f0568c3b015920261cca10'/>
<id>urn:sha1:3d2515fdd336b2c785f0568c3b015920261cca10</id>
<content type='text'>
Currently, mac80211 does not encrypt or decrypt (Re)Association frames
(Request and Response) because temporal keys are not yet available at
that stage.

With extensions from IEEE P802.11bi, e.g. EPPKE, temporal keys can be
established before association. This enables the encryption and
decryption of (Re)Association Request/Response frames.

Add support to unset the IEEE80211_TX_INTFL_DONT_ENCRYPT flag when
the peer is marked as an Enhanced Privacy Protection (EPP) peer and
encryption keys are available for the connection in non-AP STA mode,
allowing secure transmission of (Re)Association Request frames.

Drop unprotected (Re)Association Request/Response frames received from
an EPP peer.

Co-developed-by: Sai Pratyusha Magam &lt;quic_smagam@quicinc.com&gt;
Signed-off-by: Sai Pratyusha Magam &lt;quic_smagam@quicinc.com&gt;
Signed-off-by: Kavita Kavita &lt;kavita.kavita@oss.qualcomm.com&gt;
Link: https://patch.msgid.link/20260114111900.2196941-9-kavita.kavita@oss.qualcomm.com
[remove useless parentheses]
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</content>
</entry>
<entry>
<title>wifi: mac80211: Discard Beacon frames to non-broadcast address</title>
<updated>2025-12-16T09:18:00+00:00</updated>
<author>
<name>Jouni Malinen</name>
<email>jouni.malinen@oss.qualcomm.com</email>
</author>
<published>2025-12-15T15:11:34+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=193d18f60588e95d62e0f82b6a53893e5f2f19f8'/>
<id>urn:sha1:193d18f60588e95d62e0f82b6a53893e5f2f19f8</id>
<content type='text'>
Beacon frames are required to be sent to the broadcast address, see IEEE
Std 802.11-2020, 11.1.3.1 ("The Address 1 field of the Beacon .. frame
shall be set to the broadcast address"). A unicast Beacon frame might be
used as a targeted attack to get one of the associated STAs to do
something (e.g., using CSA to move it to another channel). As such, it
is better have strict filtering for this on the received side and
discard all Beacon frames that are sent to an unexpected address.

This is even more important for cases where beacon protection is used.
The current implementation in mac80211 is correctly discarding unicast
Beacon frames if the Protected Frame bit in the Frame Control field is
set to 0. However, if that bit is set to 1, the logic used for checking
for configured BIGTK(s) does not actually work. If the driver does not
have logic for dropping unicast Beacon frames with Protected Frame bit
1, these frames would be accepted in mac80211 processing as valid Beacon
frames even though they are not protected. This would allow beacon
protection to be bypassed. While the logic for checking beacon
protection could be extended to cover this corner case, a more generic
check for discard all Beacon frames based on A1=unicast address covers
this without needing additional changes.

Address all these issues by dropping received Beacon frames if they are
sent to a non-broadcast address.

Cc: stable@vger.kernel.org
Fixes: af2d14b01c32 ("mac80211: Beacon protection using the new BIGTK (STA)")
Signed-off-by: Jouni Malinen &lt;jouni.malinen@oss.qualcomm.com&gt;
Link: https://patch.msgid.link/20251215151134.104501-1-jouni.malinen@oss.qualcomm.com
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</content>
</entry>
<entry>
<title>wifi: mac80211: refactor CMAC packet handlers</title>
<updated>2025-11-20T10:56:19+00:00</updated>
<author>
<name>Chien Wong</name>
<email>m@xv97.com</email>
</author>
<published>2025-11-13T14:05:11+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=b688a9447be360d09c0982234fcd703ac7dd8c15'/>
<id>urn:sha1:b688a9447be360d09c0982234fcd703ac7dd8c15</id>
<content type='text'>
Merge CMAC-128 and CMAC-256 handlers since they are almost the same.
This removes duplication.

The comment 'MIC = AES-128-CMAC(IGTK, AAD ...' is out-dated since CMAC
is also used with BIGTK, as is the comment for CMAC-256. Simply remove
the comments.

Tested-on: mac80211_hwsim

Signed-off-by: Chien Wong &lt;m@xv97.com&gt;
Link: https://patch.msgid.link/20251113140511.48658-6-m@xv97.com
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</content>
</entry>
<entry>
<title>Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net</title>
<updated>2025-11-13T20:35:38+00:00</updated>
<author>
<name>Jakub Kicinski</name>
<email>kuba@kernel.org</email>
</author>
<published>2025-11-13T20:32:50+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=c99ebb6132595b4b288a413981197eb076547c5a'/>
<id>urn:sha1:c99ebb6132595b4b288a413981197eb076547c5a</id>
<content type='text'>
Cross-merge networking fixes after downstream PR (net-6.18-rc6).

No conflicts, adjacent changes in:

drivers/net/phy/micrel.c
  96a9178a29a6 ("net: phy: micrel: lan8814 fix reset of the QSGMII interface")
  61b7ade9ba8c ("net: phy: micrel: Add support for non PTP SKUs for lan8814")

and a trivial one in tools/testing/selftests/drivers/net/Makefile.

Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
</content>
</entry>
<entry>
<title>wifi: mac80211: skip rate verification for not captured PSDUs</title>
<updated>2025-11-11T08:25:17+00:00</updated>
<author>
<name>Benjamin Berg</name>
<email>benjamin.berg@intel.com</email>
</author>
<published>2025-11-10T12:26:18+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=7fe0d21f5633af8c3fab9f0ef0706c6156623484'/>
<id>urn:sha1:7fe0d21f5633af8c3fab9f0ef0706c6156623484</id>
<content type='text'>
If for example the sniffer did not follow any AIDs in an MU frame, then
some of the information may not be filled in or is even expected to be
invalid. As an example, in that case it is expected that Nss is zero.

Fixes: 2ff5e52e7836 ("radiotap: add 0-length PSDU "not captured" type")
Signed-off-by: Benjamin Berg &lt;benjamin.berg@intel.com&gt;
Signed-off-by: Miri Korenblit &lt;miriam.rachel.korenblit@intel.com&gt;
Link: https://patch.msgid.link/20251110142554.83a2858ee15b.I9f78ce7984872f474722f9278691ae16378f0a3e@changeid
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</content>
</entry>
</feed>
