From: Greg Kroah-Hartman Date: Fri, 30 Aug 2024 10:38:32 +0000 (+0200) Subject: 5.10-stable patches X-Git-Tag: v4.19.321~69 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=fb17e22651d6d03e9d21e986b3096a5b1f6709ab;p=thirdparty%2Fkernel%2Fstable-queue.git 5.10-stable patches added patches: mptcp-sched-check-both-backup-in-retrans.patch wifi-mwifiex-duplicate-static-structs-used-in-driver-instances.patch --- diff --git a/queue-5.10/mptcp-sched-check-both-backup-in-retrans.patch b/queue-5.10/mptcp-sched-check-both-backup-in-retrans.patch new file mode 100644 index 00000000000..d60bd8ec202 --- /dev/null +++ b/queue-5.10/mptcp-sched-check-both-backup-in-retrans.patch @@ -0,0 +1,48 @@ +From 2a1f596ebb23eadc0f9b95a8012e18ef76295fc8 Mon Sep 17 00:00:00 2001 +From: "Matthieu Baerts (NGI0)" +Date: Mon, 26 Aug 2024 19:11:20 +0200 +Subject: mptcp: sched: check both backup in retrans + +From: Matthieu Baerts (NGI0) + +commit 2a1f596ebb23eadc0f9b95a8012e18ef76295fc8 upstream. + +The 'mptcp_subflow_context' structure has two items related to the +backup flags: + + - 'backup': the subflow has been marked as backup by the other peer + + - 'request_bkup': the backup flag has been set by the host + +Looking only at the 'backup' flag can make sense in some cases, but it +is not the behaviour of the default packet scheduler when selecting +paths. + +As explained in the commit b6a66e521a20 ("mptcp: sched: check both +directions for backup"), the packet scheduler should look at both flags, +because that was the behaviour from the beginning: the 'backup' flag was +set by accident instead of the 'request_bkup' one. Now that the latter +has been fixed, get_retrans() needs to be adapted as well. + +Fixes: b6a66e521a20 ("mptcp: sched: check both directions for backup") +Cc: stable@vger.kernel.org +Reviewed-by: Mat Martineau +Signed-off-by: Matthieu Baerts (NGI0) +Link: https://patch.msgid.link/20240826-net-mptcp-close-extra-sf-fin-v1-3-905199fe1172@kernel.org +Signed-off-by: Jakub Kicinski +Signed-off-by: Greg Kroah-Hartman +--- + net/mptcp/protocol.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/net/mptcp/protocol.c ++++ b/net/mptcp/protocol.c +@@ -1664,7 +1664,7 @@ static struct sock *mptcp_subflow_get_re + return NULL; + } + +- if (subflow->backup) { ++ if (subflow->backup || subflow->request_bkup) { + if (!backup) + backup = ssk; + continue; diff --git a/queue-5.10/series b/queue-5.10/series index 6a1fc6fc869..903dd044598 100644 --- a/queue-5.10/series +++ b/queue-5.10/series @@ -124,3 +124,5 @@ drm-amdgpu-using-uninitialized-value-size-when-calling-amdgpu_vce_cs_reloc.patch kvm-arm64-don-t-use-cbz-adr-with-external-symbols.patch pinctrl-rockchip-correct-rk3328-iomux-width-flag-for-gpio2-b-pins.patch pinctrl-single-fix-potential-null-dereference-in-pcs_get_function.patch +wifi-mwifiex-duplicate-static-structs-used-in-driver-instances.patch +mptcp-sched-check-both-backup-in-retrans.patch diff --git a/queue-5.10/wifi-mwifiex-duplicate-static-structs-used-in-driver-instances.patch b/queue-5.10/wifi-mwifiex-duplicate-static-structs-used-in-driver-instances.patch new file mode 100644 index 00000000000..5a14bfbdaa4 --- /dev/null +++ b/queue-5.10/wifi-mwifiex-duplicate-static-structs-used-in-driver-instances.patch @@ -0,0 +1,84 @@ +From 27ec3c57fcadb43c79ed05b2ea31bc18c72d798a Mon Sep 17 00:00:00 2001 +From: Sascha Hauer +Date: Fri, 9 Aug 2024 10:11:33 +0200 +Subject: wifi: mwifiex: duplicate static structs used in driver instances + +From: Sascha Hauer + +commit 27ec3c57fcadb43c79ed05b2ea31bc18c72d798a upstream. + +mwifiex_band_2ghz and mwifiex_band_5ghz are statically allocated, but +used and modified in driver instances. Duplicate them before using +them in driver instances so that different driver instances do not +influence each other. + +This was observed on a board which has one PCIe and one SDIO mwifiex +adapter. It blew up in mwifiex_setup_ht_caps(). This was called with +the statically allocated struct which is modified in this function. + +Cc: stable@vger.kernel.org +Fixes: d6bffe8bb520 ("mwifiex: support for creation of AP interface") +Signed-off-by: Sascha Hauer +Reviewed-by: Francesco Dolcini +Acked-by: Brian Norris +Signed-off-by: Kalle Valo +Link: https://patch.msgid.link/20240809-mwifiex-duplicate-static-structs-v1-1-6837b903b1a4@pengutronix.de +Signed-off-by: Greg Kroah-Hartman +--- + drivers/net/wireless/marvell/mwifiex/cfg80211.c | 32 +++++++++++++++++++----- + 1 file changed, 26 insertions(+), 6 deletions(-) + +--- a/drivers/net/wireless/marvell/mwifiex/cfg80211.c ++++ b/drivers/net/wireless/marvell/mwifiex/cfg80211.c +@@ -4314,11 +4314,27 @@ int mwifiex_register_cfg80211(struct mwi + if (ISSUPP_ADHOC_ENABLED(adapter->fw_cap_info)) + wiphy->interface_modes |= BIT(NL80211_IFTYPE_ADHOC); + +- wiphy->bands[NL80211_BAND_2GHZ] = &mwifiex_band_2ghz; +- if (adapter->config_bands & BAND_A) +- wiphy->bands[NL80211_BAND_5GHZ] = &mwifiex_band_5ghz; +- else ++ wiphy->bands[NL80211_BAND_2GHZ] = devm_kmemdup(adapter->dev, ++ &mwifiex_band_2ghz, ++ sizeof(mwifiex_band_2ghz), ++ GFP_KERNEL); ++ if (!wiphy->bands[NL80211_BAND_2GHZ]) { ++ ret = -ENOMEM; ++ goto err; ++ } ++ ++ if (adapter->config_bands & BAND_A) { ++ wiphy->bands[NL80211_BAND_5GHZ] = devm_kmemdup(adapter->dev, ++ &mwifiex_band_5ghz, ++ sizeof(mwifiex_band_5ghz), ++ GFP_KERNEL); ++ if (!wiphy->bands[NL80211_BAND_5GHZ]) { ++ ret = -ENOMEM; ++ goto err; ++ } ++ } else { + wiphy->bands[NL80211_BAND_5GHZ] = NULL; ++ } + + if (adapter->drcs_enabled && ISSUPP_DRCS_ENABLED(adapter->fw_cap_info)) + wiphy->iface_combinations = &mwifiex_iface_comb_ap_sta_drcs; +@@ -4411,8 +4427,7 @@ int mwifiex_register_cfg80211(struct mwi + if (ret < 0) { + mwifiex_dbg(adapter, ERROR, + "%s: wiphy_register failed: %d\n", __func__, ret); +- wiphy_free(wiphy); +- return ret; ++ goto err; + } + + if (!adapter->regd) { +@@ -4454,4 +4469,9 @@ int mwifiex_register_cfg80211(struct mwi + + adapter->wiphy = wiphy; + return ret; ++ ++err: ++ wiphy_free(wiphy); ++ ++ return ret; + }