linux-stable.git/drivers/net, branch v6.10.3

wifi: ath12k: fix mbssid max interface advertisement

2024-08-03T07:01:09+00:00

[ Upstream commit 253ec89c9013b0e61f5c54344df7c065d54934d1 ]

The Current method for advertising the maximum MBSSID interface count
assumes single radio per wiphy (multi wiphy model). However, this
assumption is incorrect for multi radio per wiphy (single wiphy model).
Therefore, populate the parameter for each radio present in the MAC
abstraction layer (ah). This approach ensure scalability for both single
wiphy and multi wiphy models.

Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.0.1-00029-QCAHKSWPL_SILICONZ-1

Fixes: 519a545cfee7 ("wifi: ath12k: advertise driver capabilities for MBSSID and EMA")
Signed-off-by: Karthikeyan Periyasamy 
Signed-off-by: Kalle Valo 
Link: https://patch.msgid.link/20240613153813.3509837-1-quic_periyasa@quicinc.com
Signed-off-by: Sasha Levin

net: mediatek: Fix potential NULL pointer dereference in dummy net_device handling

2024-08-03T07:01:03+00:00

[ Upstream commit 16f3a28cf5f876a7f3550d8f4c870a7b41bcfaef ]

Move the freeing of the dummy net_device from mtk_free_dev() to
mtk_remove().

Previously, if alloc_netdev_dummy() failed in mtk_probe(),
eth->dummy_dev would be NULL. The error path would then call
mtk_free_dev(), which in turn called free_netdev() assuming dummy_dev
was allocated (but it was not), potentially causing a NULL pointer
dereference.

By moving free_netdev() to mtk_remove(), we ensure it's only called when
mtk_probe() has succeeded and dummy_dev is fully allocated. This
addresses a potential NULL pointer dereference detected by Smatch[1].

Fixes: b209bd6d0bff ("net: mediatek: mtk_eth_sock: allocate dummy net_device dynamically")
Reported-by: Dan Carpenter 
Closes: https://lore.kernel.org/all/4160f4e0-cbef-4a22-8b5d-42c4d399e1f7@stanley.mountain/ [1]
Suggested-by: Dan Carpenter 
Reviewed-by: Dan Carpenter 
Signed-off-by: Breno Leitao 
Reviewed-by: Simon Horman 
Link: https://patch.msgid.link/20240724080524.2734499-1-leitao@debian.org
Signed-off-by: Paolo Abeni 
Signed-off-by: Sasha Levin

net: stmmac: Correct byte order of perfect_match

2024-08-03T07:01:03+00:00

[ Upstream commit e9dbebae2e3c338122716914fe105458f41e3a4a ]

The perfect_match parameter of the update_vlan_hash operation is __le16,
and is correctly converted from host byte-order in the lone caller,
stmmac_vlan_update().

However, the implementations of this caller, dwxgmac2_update_vlan_hash()
and dwxgmac2_update_vlan_hash(), both treat this parameter as host byte
order, using the following pattern:

	u32 value = ...
	...
	writel(value | perfect_match, ...);

This is not correct because both:
1) value is host byte order; and
2) writel expects a host byte order value as it's first argument

I believe that this will break on big endian systems. And I expect it
has gone unnoticed by only being exercised on little endian systems.

The approach taken by this patch is to update the callback, and it's
caller to simply use a host byte order value.

Flagged by Sparse.
Compile tested only.

Fixes: c7ab0b8088d7 ("net: stmmac: Fallback to VLAN Perfect filtering if HASH is not available")
Signed-off-by: Simon Horman 
Reviewed-by: Maxime Chevallier 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin

ice: Fix recipe read procedure

2024-08-03T07:01:02+00:00

[ Upstream commit 19abb9c2b900bad59e0a9818d6c83bb4cc875437 ]

When ice driver reads recipes from firmware information about
need_pass_l2 and allow_pass_l2 flags is not stored correctly.
Those flags are stored as one bit each in ice_sw_recipe structure.
Because of that, the result of checking a flag has to be casted to bool.
Note that the need_pass_l2 flag currently works correctly, because
it's stored in the first bit.

Fixes: bccd9bce29e0 ("ice: Add guard rule when creating FDB in switchdev")
Reviewed-by: Marcin Szycik 
Reviewed-by: Przemek Kitszel 
Signed-off-by: Wojciech Drewek 
Reviewed-by: Simon Horman 
Tested-by: Sujai Buvaneswaran 
Signed-off-by: Tony Nguyen 
Signed-off-by: Sasha Levin

net: bonding: correctly annotate RCU in bond_should_notify_peers()

2024-08-03T07:01:02+00:00

[ Upstream commit 3ba359c0cd6eb5ea772125a7aededb4a2d516684 ]

RCU use in bond_should_notify_peers() looks wrong, since it does
rcu_dereference(), leaves the critical section, and uses the
pointer after that.

Luckily, it's called either inside a nested RCU critical section
or with the RTNL held.

Annotate it with rcu_dereference_rtnl() instead, and remove the
inner RCU critical section.

Fixes: 4cb4f97b7e36 ("bonding: rebuild the lock use for bond_mii_monitor()")
Reviewed-by: Jiri Pirko 
Signed-off-by: Johannes Berg 
Acked-by: Jay Vosburgh 
Link: https://patch.msgid.link/20240719094119.35c62455087d.I68eb9c0f02545b364b79a59f2110f2cf5682a8e2@changeid
Signed-off-by: Paolo Abeni 
Signed-off-by: Sasha Levin

ice: Add a per-VF limit on number of FDIR filters

2024-08-03T07:00:49+00:00

commit 6ebbe97a488179f5dc85f2f1e0c89b486e99ee97 upstream.

While the iavf driver adds a s/w limit (128) on the number of FDIR
filters that the VF can request, a malicious VF driver can request more
than that and exhaust the resources for other VFs.

Add a similar limit in ice.

CC: stable@vger.kernel.org
Fixes: 1f7ea1cd6a37 ("ice: Enable FDIR Configure for AVF")
Reviewed-by: Przemek Kitszel 
Suggested-by: Sridhar Samudrala 
Signed-off-by: Ahmed Zaki 
Reviewed-by: Wojciech Drewek 
Tested-by: Rafal Romanowski 
Signed-off-by: Tony Nguyen 
Signed-off-by: Greg Kroah-Hartman

gve: Fix an edge case for TSO skb validity check

2024-08-03T07:00:49+00:00

commit 36e3b949e35964e22b9a57f960660fc599038dd4 upstream.

The NIC requires each TSO segment to not span more than 10
descriptors. NIC further requires each descriptor to not exceed
16KB - 1 (GVE_TX_MAX_BUF_SIZE_DQO).

The descriptors for an skb are generated by
gve_tx_add_skb_no_copy_dqo() for DQO RDA queue format.
gve_tx_add_skb_no_copy_dqo() loops through each skb frag and
generates a descriptor for the entire frag if the frag size is
not greater than GVE_TX_MAX_BUF_SIZE_DQO. If the frag size is
greater than GVE_TX_MAX_BUF_SIZE_DQO, it is split into descriptor(s)
of size GVE_TX_MAX_BUF_SIZE_DQO and a descriptor is generated for
the remainder (frag size % GVE_TX_MAX_BUF_SIZE_DQO).

gve_can_send_tso() checks if the descriptors thus generated for an
skb would meet the requirement that each TSO-segment not span more
than 10 descriptors. However, the current code misses an edge case
when a TSO segment spans multiple descriptors within a large frag.
This change fixes the edge case.

gve_can_send_tso() relies on the assumption that max gso size (9728)
is less than GVE_TX_MAX_BUF_SIZE_DQO and therefore within an skb
fragment a TSO segment can never span more than 2 descriptors.

Fixes: a57e5de476be ("gve: DQO: Add TX path")
Signed-off-by: Praveen Kaligineedi 
Signed-off-by: Bailey Forrest 
Reviewed-by: Jeroen de Borst 
Cc: stable@vger.kernel.org
Reviewed-by: Willem de Bruijn 
Link: https://patch.msgid.link/20240724143431.3343722-1-pkaligineedi@google.com
Signed-off-by: Jakub Kicinski 
Signed-off-by: Greg Kroah-Hartman

wifi: rtw88: usb: Further limit the TX aggregation

2024-08-03T07:00:38+00:00

commit d7dd13ea54af8496aca2762a758d817d6813e81c upstream.

Currently the number of frames sent to the chip in a single USB Request
Block is limited only by the size of the TX buffer, which is 20 KiB.
Testing reveals that as many as 13 frames get aggregated. This is more
than what any of the chips would like to receive. RTL8822CU, RTL8822BU,
and RTL8821CU want at most 3 frames, and RTL8723DU wants only 1 frame
per URB.

RTL8723DU in particular reliably malfunctions during a speed test if it
receives more than 1 frame per URB. All traffic seems to stop. Pinging
the AP no longer works.

Fix this problem by limiting the number of frames sent to the chip in a
single URB according to what each chip likes.

Also configure RTL8822CU, RTL8822BU, and RTL8821CU to expect 3 frames
per URB.

RTL8703B may or may not be found in USB devices. Declare that it wants
only 1 frame per URB, just in case.

Tested with RTL8723DU and RTL8811CU.

Cc: stable@vger.kernel.org
Signed-off-by: Bitterblue Smith 
Acked-by: Ping-Ke Shih 
Signed-off-by: Ping-Ke Shih 
Link: https://patch.msgid.link/cb46ea35-7e59-4742-9c1f-01ceeaad36fb@gmail.com
Signed-off-by: Greg Kroah-Hartman

wifi: rtw88: usb: Fix disconnection after beacon loss

2024-08-03T07:00:38+00:00

commit 28818b4d871bc93cc4f5c7c7d7c526a6a096c09c upstream.

When there is beacon loss, for example due to unrelated Bluetooth
devices transmitting music nearby, the wifi connection dies soon
after the first beacon loss message:

Apr 28 20:47:14 ideapad2 wpa_supplicant[1161]: wlp3s0f3u4:
 CTRL-EVENT-BEACON-LOSS
Apr 28 20:47:15 ideapad2 wpa_supplicant[1161]: wlp3s0f3u4:
 CTRL-EVENT-DISCONNECTED bssid=... reason=4 locally_generated=1

Apr 28 20:47:24 ideapad2 wpa_supplicant[1161]: wlp3s0f3u4:
 CTRL-EVENT-BEACON-LOSS
Apr 28 20:47:25 ideapad2 wpa_supplicant[1161]: wlp3s0f3u4:
 CTRL-EVENT-DISCONNECTED bssid=... reason=4 locally_generated=1

Apr 28 20:47:34 ideapad2 wpa_supplicant[1161]: wlp3s0f3u4:
 CTRL-EVENT-BEACON-LOSS
Apr 28 20:47:35 ideapad2 wpa_supplicant[1161]: wlp3s0f3u4:
 CTRL-EVENT-DISCONNECTED bssid=... reason=4 locally_generated=1

When the beacon loss happens, mac80211 makes rtw88 transmit a QOS
NULL frame and asks to confirm the ACK status. Even though rtw88
confirms to mac80211 that the QOS NULL was transmitted successfully,
the connection still dies. This is because rtw88 is handing the QOS
NULL back to mac80211 with skb->data pointing to the headroom (the
TX descriptor) instead of ieee80211_hdr.

Fix the disconnection by moving skb->data to the correct position
before ieee80211_tx_status_irqsafe().

The problem was observed with RTL8811AU (TP-Link Archer T2U Nano)
and the potential future rtw88_8821au driver. Also tested with
RTL8811CU (Tenda U9).

Cc: stable@vger.kernel.org
Signed-off-by: Bitterblue Smith 
Signed-off-by: Ping-Ke Shih 
Link: https://msgid.link/ecbf0601-810d-4609-b8fc-8b0e38d2948d@gmail.com
Signed-off-by: Greg Kroah-Hartman

wifi: rtw89: fix HW scan not aborting properly

2024-08-03T07:00:38+00:00

commit 669b692247d4516e252c898c0e7366a09d84d1be upstream.

There is a length limit on the commands we send to firmware, so
dividing to two commands is sometimes required when scanning.
When aborting scan, we should not send second scan command to
firmware after the first one is finished. This could cause some
unexpected errors when we cannot receive firmware events
(e.g. in suspend).

Another case is scan happens before suspending, ieee80211_do_stop() is
called to abort scan and driver indicate scan completion by
ieee80211_scan_completed(), which queues event to scan work. But scan work
might be late to execute after ieee80211_do_stop(). To correct this, driver
indicates ieee80211_scan_completed() before returning, so that
ieee80211_do_stop() can flush scan work properly.

Fixes: bcbefbd032df ("wifi: rtw89: add wait/completion for abort scan")
Cc: stable@vger.kernel.org
Co-developed-by: Chih-Kang Chang 
Signed-off-by: Chih-Kang Chang 
Signed-off-by: Po-Hao Huang 
Signed-off-by: Ping-Ke Shih 
Link: https://msgid.link/20240517013350.11278-1-pkshih@realtek.com
Signed-off-by: Greg Kroah-Hartman