--- /dev/null
+From 96a64e9730c2c76cfa5c510583a0fbf40d62886b Mon Sep 17 00:00:00 2001
+From: Andreas Kemnade <andreas@kemnade.info>
+Date: Fri, 18 Oct 2024 23:47:27 +0200
+Subject: ARM: dts: omap36xx: declare 1GHz OPP as turbo again
+
+From: Andreas Kemnade <andreas@kemnade.info>
+
+commit 96a64e9730c2c76cfa5c510583a0fbf40d62886b upstream.
+
+Operating stable without reduced chip life at 1Ghz needs several
+technologies working: The technologies involve
+- SmartReflex
+- DVFS
+
+As this cannot directly specified in the OPP table as dependecies in the
+devicetree yet, use the turbo flag again to mark this OPP as something
+special to have some kind of opt-in.
+
+So revert commit
+5f1bf7ae8481 ("ARM: dts: omap36xx: Remove turbo mode for 1GHz variants")
+
+Practical reasoning:
+At least the GTA04A5 (DM3730) has become unstable with that OPP enabled.
+Furthermore nothing enforces the availability of said technologies,
+even in the kernel configuration, so allow users to rather opt-in.
+
+Cc: Stable@vger.kernel.org
+Fixes: 5f1bf7ae8481 ("ARM: dts: omap36xx: Remove turbo mode for 1GHz variants")
+Signed-off-by: Andreas Kemnade <andreas@kemnade.info>
+Link: https://lore.kernel.org/r/20241018214727.275162-1-andreas@kemnade.info
+Signed-off-by: Kevin Hilman <khilman@baylibre.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/arm/boot/dts/ti/omap/omap36xx.dtsi | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/arch/arm/boot/dts/ti/omap/omap36xx.dtsi
++++ b/arch/arm/boot/dts/ti/omap/omap36xx.dtsi
+@@ -72,6 +72,7 @@
+ <1375000 1375000 1375000>;
+ /* only on am/dm37x with speed-binned bit set */
+ opp-supported-hw = <0xffffffff 2>;
++ turbo-mode;
+ };
+ };
+
--- /dev/null
+From b9aef1b13a0a92aa7058ba235afb24b5b89153ca Mon Sep 17 00:00:00 2001
+From: Meetakshi Setiya <msetiya@microsoft.com>
+Date: Wed, 30 Oct 2024 05:37:21 -0400
+Subject: cifs: support mounting with alternate password to allow password rotation
+
+From: Meetakshi Setiya <msetiya@microsoft.com>
+
+commit b9aef1b13a0a92aa7058ba235afb24b5b89153ca upstream.
+
+Fixes the case for example where the password specified on mount is a
+recently expired password, but password2 is valid. Without this patch
+this mount scenario would fail.
+
+This patch introduces the following changes to support password rotation on
+mount:
+
+1. If an existing session is not found and the new session setup results in
+EACCES, EKEYEXPIRED or EKEYREVOKED, swap password and password2 (if
+available), and retry the mount.
+
+2. To match the new mount with an existing session, add conditions to check
+if a) password and password2 of the new mount and the existing session are
+the same, or b) password of the new mount is the same as the password2 of
+the existing session, and password2 of the new mount is the same as the
+password of the existing session.
+
+3. If an existing session is found, but needs reconnect, retry the session
+setup after swapping password and password2 (if available), in case the
+previous attempt results in EACCES, EKEYEXPIRED or EKEYREVOKED.
+
+Cc: stable@vger.kernel.org
+Signed-off-by: Meetakshi Setiya <msetiya@microsoft.com>
+Signed-off-by: Steve French <stfrench@microsoft.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/smb/client/connect.c | 57 ++++++++++++++++++++++++++++++++++++++++++------
+ 1 file changed, 50 insertions(+), 7 deletions(-)
+
+--- a/fs/smb/client/connect.c
++++ b/fs/smb/client/connect.c
+@@ -1908,11 +1908,35 @@ static int match_session(struct cifs_ses
+ CIFS_MAX_USERNAME_LEN))
+ return 0;
+ if ((ctx->username && strlen(ctx->username) != 0) &&
+- ses->password != NULL &&
+- strncmp(ses->password,
+- ctx->password ? ctx->password : "",
+- CIFS_MAX_PASSWORD_LEN))
+- return 0;
++ ses->password != NULL) {
++
++ /* New mount can only share sessions with an existing mount if:
++ * 1. Both password and password2 match, or
++ * 2. password2 of the old mount matches password of the new mount
++ * and password of the old mount matches password2 of the new
++ * mount
++ */
++ if (ses->password2 != NULL && ctx->password2 != NULL) {
++ if (!((strncmp(ses->password, ctx->password ?
++ ctx->password : "", CIFS_MAX_PASSWORD_LEN) == 0 &&
++ strncmp(ses->password2, ctx->password2,
++ CIFS_MAX_PASSWORD_LEN) == 0) ||
++ (strncmp(ses->password, ctx->password2,
++ CIFS_MAX_PASSWORD_LEN) == 0 &&
++ strncmp(ses->password2, ctx->password ?
++ ctx->password : "", CIFS_MAX_PASSWORD_LEN) == 0)))
++ return 0;
++
++ } else if ((ses->password2 == NULL && ctx->password2 != NULL) ||
++ (ses->password2 != NULL && ctx->password2 == NULL)) {
++ return 0;
++
++ } else {
++ if (strncmp(ses->password, ctx->password ?
++ ctx->password : "", CIFS_MAX_PASSWORD_LEN))
++ return 0;
++ }
++ }
+ }
+
+ if (strcmp(ctx->local_nls->charset, ses->local_nls->charset))
+@@ -2256,6 +2280,7 @@ struct cifs_ses *
+ cifs_get_smb_ses(struct TCP_Server_Info *server, struct smb3_fs_context *ctx)
+ {
+ int rc = 0;
++ int retries = 0;
+ unsigned int xid;
+ struct cifs_ses *ses;
+ struct sockaddr_in *addr = (struct sockaddr_in *)&server->dstaddr;
+@@ -2274,6 +2299,8 @@ cifs_get_smb_ses(struct TCP_Server_Info
+ cifs_dbg(FYI, "Session needs reconnect\n");
+
+ mutex_lock(&ses->session_mutex);
++
++retry_old_session:
+ rc = cifs_negotiate_protocol(xid, ses, server);
+ if (rc) {
+ mutex_unlock(&ses->session_mutex);
+@@ -2286,6 +2313,13 @@ cifs_get_smb_ses(struct TCP_Server_Info
+ rc = cifs_setup_session(xid, ses, server,
+ ctx->local_nls);
+ if (rc) {
++ if (((rc == -EACCES) || (rc == -EKEYEXPIRED) ||
++ (rc == -EKEYREVOKED)) && !retries && ses->password2) {
++ retries++;
++ cifs_dbg(FYI, "Session reconnect failed, retrying with alternate password\n");
++ swap(ses->password, ses->password2);
++ goto retry_old_session;
++ }
+ mutex_unlock(&ses->session_mutex);
+ /* problem -- put our reference */
+ cifs_put_smb_ses(ses);
+@@ -2361,6 +2395,7 @@ cifs_get_smb_ses(struct TCP_Server_Info
+ ses->chans_need_reconnect = 1;
+ spin_unlock(&ses->chan_lock);
+
++retry_new_session:
+ mutex_lock(&ses->session_mutex);
+ rc = cifs_negotiate_protocol(xid, ses, server);
+ if (!rc)
+@@ -2373,8 +2408,16 @@ cifs_get_smb_ses(struct TCP_Server_Info
+ sizeof(ses->smb3signingkey));
+ spin_unlock(&ses->chan_lock);
+
+- if (rc)
+- goto get_ses_fail;
++ if (rc) {
++ if (((rc == -EACCES) || (rc == -EKEYEXPIRED) ||
++ (rc == -EKEYREVOKED)) && !retries && ses->password2) {
++ retries++;
++ cifs_dbg(FYI, "Session setup failed, retrying with alternate password\n");
++ swap(ses->password, ses->password2);
++ goto retry_new_session;
++ } else
++ goto get_ses_fail;
++ }
+
+ /*
+ * success, put it on the list and add it as first channel
--- /dev/null
+From 172bf5ed04cb6c9e66d58de003938ed5c8756570 Mon Sep 17 00:00:00 2001
+From: Jinjie Ruan <ruanjinjie@huawei.com>
+Date: Thu, 7 Nov 2024 19:38:41 +0800
+Subject: cpufreq: mediatek-hw: Fix wrong return value in mtk_cpufreq_get_cpu_power()
+
+From: Jinjie Ruan <ruanjinjie@huawei.com>
+
+commit 172bf5ed04cb6c9e66d58de003938ed5c8756570 upstream.
+
+mtk_cpufreq_get_cpu_power() return 0 if the policy is NULL. Then in
+em_create_perf_table(), the later zero check for power is not invalid
+as power is uninitialized. As Lukasz suggested, it must return -EINVAL when
+the 'policy' is not found. So return -EINVAL to fix it.
+
+Cc: stable@vger.kernel.org
+Fixes: 4855e26bcf4d ("cpufreq: mediatek-hw: Add support for CPUFREQ HW")
+Reviewed-by: Lukasz Luba <lukasz.luba@arm.com>
+Suggested-by: Lukasz Luba <lukasz.luba@arm.com>
+Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
+Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/cpufreq/mediatek-cpufreq-hw.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/cpufreq/mediatek-cpufreq-hw.c
++++ b/drivers/cpufreq/mediatek-cpufreq-hw.c
+@@ -62,7 +62,7 @@ mtk_cpufreq_get_cpu_power(struct device
+
+ policy = cpufreq_cpu_get_raw(cpu_dev->id);
+ if (!policy)
+- return 0;
++ return -EINVAL;
+
+ data = policy->driver_data;
+
--- /dev/null
+From 72cef64180de04a7b055b4773c138d78f4ebdb77 Mon Sep 17 00:00:00 2001
+From: Sai Kumar Cholleti <skmr537@gmail.com>
+Date: Tue, 5 Nov 2024 12:45:23 +0530
+Subject: gpio: exar: set value when external pull-up or pull-down is present
+
+From: Sai Kumar Cholleti <skmr537@gmail.com>
+
+commit 72cef64180de04a7b055b4773c138d78f4ebdb77 upstream.
+
+Setting GPIO direction = high, sometimes results in GPIO value = 0.
+
+If a GPIO is pulled high, the following construction results in the
+value being 0 when the desired value is 1:
+
+$ echo "high" > /sys/class/gpio/gpio336/direction
+$ cat /sys/class/gpio/gpio336/value
+0
+
+Before the GPIO direction is changed from an input to an output,
+exar_set_value() is called with value = 1, but since the GPIO is an
+input when exar_set_value() is called, _regmap_update_bits() reads a 1
+due to an external pull-up. regmap_set_bits() sets force_write =
+false, so the value (1) is not written. When the direction is then
+changed, the GPIO becomes an output with the value of 0 (the hardware
+default).
+
+regmap_write_bits() sets force_write = true, so the value is always
+written by exar_set_value() and an external pull-up doesn't affect the
+outcome of setting direction = high.
+
+The same can happen when a GPIO is pulled low, but the scenario is a
+little more complicated.
+
+$ echo high > /sys/class/gpio/gpio351/direction
+$ cat /sys/class/gpio/gpio351/value
+1
+
+$ echo in > /sys/class/gpio/gpio351/direction
+$ cat /sys/class/gpio/gpio351/value
+0
+
+$ echo low > /sys/class/gpio/gpio351/direction
+$ cat /sys/class/gpio/gpio351/value
+1
+
+Fixes: 36fb7218e878 ("gpio: exar: switch to using regmap")
+Co-developed-by: Matthew McClain <mmcclain@noprivs.com>
+Signed-off-by: Matthew McClain <mmcclain@noprivs.com>
+Signed-off-by: Sai Kumar Cholleti <skmr537@gmail.com>
+Cc: stable@vger.kernel.org
+Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
+Link: https://lore.kernel.org/r/20241105071523.2372032-1-skmr537@gmail.com
+Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpio/gpio-exar.c | 10 ++++++----
+ 1 file changed, 6 insertions(+), 4 deletions(-)
+
+--- a/drivers/gpio/gpio-exar.c
++++ b/drivers/gpio/gpio-exar.c
+@@ -99,11 +99,13 @@ static void exar_set_value(struct gpio_c
+ struct exar_gpio_chip *exar_gpio = gpiochip_get_data(chip);
+ unsigned int addr = exar_offset_to_lvl_addr(exar_gpio, offset);
+ unsigned int bit = exar_offset_to_bit(exar_gpio, offset);
++ unsigned int bit_value = value ? BIT(bit) : 0;
+
+- if (value)
+- regmap_set_bits(exar_gpio->regmap, addr, BIT(bit));
+- else
+- regmap_clear_bits(exar_gpio->regmap, addr, BIT(bit));
++ /*
++ * regmap_write_bits() forces value to be written when an external
++ * pull up/down might otherwise indicate value was already set.
++ */
++ regmap_write_bits(exar_gpio->regmap, addr, BIT(bit), bit_value);
+ }
+
+ static int exar_direction_output(struct gpio_chip *chip, unsigned int offset,
--- /dev/null
+From 9a8c5d89d327ff58e9b2517f8a6afb4181d32c6e Mon Sep 17 00:00:00 2001
+From: Yunseong Kim <yskelg@gmail.com>
+Date: Mon, 25 Nov 2024 16:45:55 +0900
+Subject: ksmbd: fix use-after-free in SMB request handling
+
+From: Yunseong Kim <yskelg@gmail.com>
+
+commit 9a8c5d89d327ff58e9b2517f8a6afb4181d32c6e upstream.
+
+A race condition exists between SMB request handling in
+`ksmbd_conn_handler_loop()` and the freeing of `ksmbd_conn` in the
+workqueue handler `handle_ksmbd_work()`. This leads to a UAF.
+- KASAN: slab-use-after-free Read in handle_ksmbd_work
+- KASAN: slab-use-after-free in rtlock_slowlock_locked
+
+This race condition arises as follows:
+- `ksmbd_conn_handler_loop()` waits for `conn->r_count` to reach zero:
+ `wait_event(conn->r_count_q, atomic_read(&conn->r_count) == 0);`
+- Meanwhile, `handle_ksmbd_work()` decrements `conn->r_count` using
+ `atomic_dec_return(&conn->r_count)`, and if it reaches zero, calls
+ `ksmbd_conn_free()`, which frees `conn`.
+- However, after `handle_ksmbd_work()` decrements `conn->r_count`,
+ it may still access `conn->r_count_q` in the following line:
+ `waitqueue_active(&conn->r_count_q)` or `wake_up(&conn->r_count_q)`
+ This results in a UAF, as `conn` has already been freed.
+
+The discovery of this UAF can be referenced in the following PR for
+syzkaller's support for SMB requests.
+Link: https://github.com/google/syzkaller/pull/5524
+
+Fixes: ee426bfb9d09 ("ksmbd: add refcnt to ksmbd_conn struct")
+Cc: linux-cifs@vger.kernel.org
+Cc: stable@vger.kernel.org # v6.6.55+, v6.10.14+, v6.11.3+
+Cc: syzkaller@googlegroups.com
+Signed-off-by: Yunseong Kim <yskelg@gmail.com>
+Acked-by: Namjae Jeon <linkinjeon@kernel.org>
+Signed-off-by: Steve French <stfrench@microsoft.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/smb/server/server.c | 4 ++++
+ 1 file changed, 4 insertions(+)
+
+diff --git a/fs/smb/server/server.c b/fs/smb/server/server.c
+index b3dceefe6c5f..930d7566b52e 100644
+--- a/fs/smb/server/server.c
++++ b/fs/smb/server/server.c
+@@ -276,8 +276,12 @@ static void handle_ksmbd_work(struct work_struct *wk)
+ * disconnection. waitqueue_active is safe because it
+ * uses atomic operation for condition.
+ */
++ atomic_inc(&conn->refcnt);
+ if (!atomic_dec_return(&conn->r_count) && waitqueue_active(&conn->r_count_q))
+ wake_up(&conn->r_count_q);
++
++ if (atomic_dec_and_test(&conn->refcnt))
++ kfree(conn);
+ }
+
+ /**
+--
+2.47.1
+
--- /dev/null
+From 98d1fb94ce75f39febd456d6d3cbbe58b6678795 Mon Sep 17 00:00:00 2001
+From: Cheng Ming Lin <chengminglin@mxic.com.tw>
+Date: Tue, 12 Nov 2024 15:52:42 +0800
+Subject: mtd: spi-nor: core: replace dummy buswidth from addr to data
+
+From: Cheng Ming Lin <chengminglin@mxic.com.tw>
+
+commit 98d1fb94ce75f39febd456d6d3cbbe58b6678795 upstream.
+
+The default dummy cycle for Macronix SPI NOR flash in Octal Output
+Read Mode(1-1-8) is 20.
+
+Currently, the dummy buswidth is set according to the address bus width.
+In the 1-1-8 mode, this means the dummy buswidth is 1. When converting
+dummy cycles to bytes, this results in 20 x 1 / 8 = 2 bytes, causing the
+host to read data 4 cycles too early.
+
+Since the protocol data buswidth is always greater than or equal to the
+address buswidth. Setting the dummy buswidth to match the data buswidth
+increases the likelihood that the dummy cycle-to-byte conversion will be
+divisible, preventing the host from reading data prematurely.
+
+Fixes: 0e30f47232ab ("mtd: spi-nor: add support for DTR protocol")
+Cc: stable@vger.kernel.org
+Reviewed-by: Pratyush Yadav <pratyush@kernel.org>
+Signed-off-by: Cheng Ming Lin <chengminglin@mxic.com.tw>
+Link: https://lore.kernel.org/r/20241112075242.174010-2-linchengming884@gmail.com
+Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/mtd/spi-nor/core.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/mtd/spi-nor/core.c
++++ b/drivers/mtd/spi-nor/core.c
+@@ -89,7 +89,7 @@ void spi_nor_spimem_setup_op(const struc
+ op->addr.buswidth = spi_nor_get_protocol_addr_nbits(proto);
+
+ if (op->dummy.nbytes)
+- op->dummy.buswidth = spi_nor_get_protocol_addr_nbits(proto);
++ op->dummy.buswidth = spi_nor_get_protocol_data_nbits(proto);
+
+ if (op->data.nbytes)
+ op->data.buswidth = spi_nor_get_protocol_data_nbits(proto);
--- /dev/null
+From 35f56c554eb1b56b77b3cf197a6b00922d49033d Mon Sep 17 00:00:00 2001
+From: Jeongjun Park <aha310510@gmail.com>
+Date: Wed, 13 Nov 2024 22:02:09 +0900
+Subject: netfilter: ipset: add missing range check in bitmap_ip_uadt
+
+From: Jeongjun Park <aha310510@gmail.com>
+
+commit 35f56c554eb1b56b77b3cf197a6b00922d49033d upstream.
+
+When tb[IPSET_ATTR_IP_TO] is not present but tb[IPSET_ATTR_CIDR] exists,
+the values of ip and ip_to are slightly swapped. Therefore, the range check
+for ip should be done later, but this part is missing and it seems that the
+vulnerability occurs.
+
+So we should add missing range checks and remove unnecessary range checks.
+
+Cc: <stable@vger.kernel.org>
+Reported-by: syzbot+58c872f7790a4d2ac951@syzkaller.appspotmail.com
+Fixes: 72205fc68bd1 ("netfilter: ipset: bitmap:ip set type support")
+Signed-off-by: Jeongjun Park <aha310510@gmail.com>
+Acked-by: Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>
+Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/netfilter/ipset/ip_set_bitmap_ip.c | 7 ++-----
+ 1 file changed, 2 insertions(+), 5 deletions(-)
+
+--- a/net/netfilter/ipset/ip_set_bitmap_ip.c
++++ b/net/netfilter/ipset/ip_set_bitmap_ip.c
+@@ -163,11 +163,8 @@ bitmap_ip_uadt(struct ip_set *set, struc
+ ret = ip_set_get_hostipaddr4(tb[IPSET_ATTR_IP_TO], &ip_to);
+ if (ret)
+ return ret;
+- if (ip > ip_to) {
++ if (ip > ip_to)
+ swap(ip, ip_to);
+- if (ip < map->first_ip)
+- return -IPSET_ERR_BITMAP_RANGE;
+- }
+ } else if (tb[IPSET_ATTR_CIDR]) {
+ u8 cidr = nla_get_u8(tb[IPSET_ATTR_CIDR]);
+
+@@ -178,7 +175,7 @@ bitmap_ip_uadt(struct ip_set *set, struc
+ ip_to = ip;
+ }
+
+- if (ip_to > map->last_ip)
++ if (ip < map->first_ip || ip_to > map->last_ip)
+ return -IPSET_ERR_BITMAP_RANGE;
+
+ for (; !before(ip_to, ip); ip += map->hosts) {
--- /dev/null
+From a5f05a138a8cac035bf9da9b6ed0e532bc7942c8 Mon Sep 17 00:00:00 2001
+From: Josh Poimboeuf <jpoimboe@kernel.org>
+Date: Wed, 2 Oct 2024 14:32:04 -0700
+Subject: parisc/ftrace: Fix function graph tracing disablement
+
+From: Josh Poimboeuf <jpoimboe@kernel.org>
+
+commit a5f05a138a8cac035bf9da9b6ed0e532bc7942c8 upstream.
+
+Due to an apparent copy-paste bug, the parisc implementation of
+ftrace_disable_ftrace_graph_caller() doesn't actually do anything.
+It enables the (already-enabled) static key rather than disabling it.
+
+The result is that after function graph tracing has been "disabled", any
+subsequent (non-graph) function tracing will inadvertently also enable
+the slow fgraph return address hijacking.
+
+Fixes: 98f2926171ae ("parisc/ftrace: use static key to enable/disable function graph tracer")
+Cc: stable@vger.kernel.org # 5.16+
+Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org>
+Signed-off-by: Helge Deller <deller@gmx.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/parisc/kernel/ftrace.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/arch/parisc/kernel/ftrace.c
++++ b/arch/parisc/kernel/ftrace.c
+@@ -87,7 +87,7 @@ int ftrace_enable_ftrace_graph_caller(vo
+
+ int ftrace_disable_ftrace_graph_caller(void)
+ {
+- static_key_enable(&ftrace_graph_enable.key);
++ static_key_disable(&ftrace_graph_enable.key);
+ return 0;
+ }
+ #endif
--- /dev/null
+From 9c41f371457bd9a24874e3c7934d9745e87fbc58 Mon Sep 17 00:00:00 2001
+From: Javier Carrasco <javier.carrasco.cruz@gmail.com>
+Date: Sun, 13 Oct 2024 15:20:24 +0200
+Subject: platform/chrome: cros_ec_typec: fix missing fwnode reference decrement
+
+From: Javier Carrasco <javier.carrasco.cruz@gmail.com>
+
+commit 9c41f371457bd9a24874e3c7934d9745e87fbc58 upstream.
+
+The device_for_each_child_node() macro requires explicit calls to
+fwnode_handle_put() upon early exits (return, break, goto) to decrement
+the fwnode's refcount, and avoid levaing a node reference behind.
+
+Add the missing fwnode_handle_put() after the common label for all error
+paths.
+
+Cc: stable@vger.kernel.org
+Fixes: fdc6b21e2444 ("platform/chrome: Add Type C connector class driver")
+Signed-off-by: Javier Carrasco <javier.carrasco.cruz@gmail.com>
+Link: https://lore.kernel.org/r/20241013-cross_ec_typec_fwnode_handle_put-v2-1-9182b2cd7767@gmail.com
+Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/platform/chrome/cros_ec_typec.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/platform/chrome/cros_ec_typec.c
++++ b/drivers/platform/chrome/cros_ec_typec.c
+@@ -390,6 +390,7 @@ static int cros_typec_init_ports(struct
+ return 0;
+
+ unregister_ports:
++ fwnode_handle_put(fwnode);
+ cros_unregister_ports(typec);
+ return ret;
+ }
--- /dev/null
+From 718632467d88e98816fa01ab12681ef1c2aa56f8 Mon Sep 17 00:00:00 2001
+From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Date: Sat, 30 Nov 2024 16:55:56 +0100
+Subject: Revert "serial: sh-sci: Clean sci_ports[0] after at earlycon exit"
+
+From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+commit 718632467d88e98816fa01ab12681ef1c2aa56f8 upstream.
+
+This reverts commit 3791ea69a4858b81e0277f695ca40f5aae40f312.
+
+It was reported to cause boot-time issues, so revert it for now.
+
+Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>
+Fixes: 3791ea69a485 ("serial: sh-sci: Clean sci_ports[0] after at earlycon exit")
+Cc: stable <stable@kernel.org>
+Cc: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/tty/serial/sh-sci.c | 28 ----------------------------
+ 1 file changed, 28 deletions(-)
+
+--- a/drivers/tty/serial/sh-sci.c
++++ b/drivers/tty/serial/sh-sci.c
+@@ -3505,32 +3505,6 @@ sh_early_platform_init_buffer("earlyprin
+ #ifdef CONFIG_SERIAL_SH_SCI_EARLYCON
+ static struct plat_sci_port port_cfg __initdata;
+
+-static int early_console_exit(struct console *co)
+-{
+- struct sci_port *sci_port = &sci_ports[0];
+- struct uart_port *port = &sci_port->port;
+- unsigned long flags;
+- int locked = 1;
+-
+- if (port->sysrq)
+- locked = 0;
+- else if (oops_in_progress)
+- locked = uart_port_trylock_irqsave(port, &flags);
+- else
+- uart_port_lock_irqsave(port, &flags);
+-
+- /*
+- * Clean the slot used by earlycon. A new SCI device might
+- * map to this slot.
+- */
+- memset(sci_ports, 0, sizeof(*sci_port));
+-
+- if (locked)
+- uart_port_unlock_irqrestore(port, flags);
+-
+- return 0;
+-}
+-
+ static int __init early_console_setup(struct earlycon_device *device,
+ int type)
+ {
+@@ -3549,8 +3523,6 @@ static int __init early_console_setup(st
+ SCSCR_RE | SCSCR_TE | port_cfg.scscr);
+
+ device->con->write = serial_console_write;
+- device->con->exit = early_console_exit;
+-
+ return 0;
+ }
+ static int __init sci_early_console_setup(struct earlycon_device *device,
--- /dev/null
+From 51cdd69d6a857f527d6d0697a2e1f0fa8bca1005 Mon Sep 17 00:00:00 2001
+From: Michal Vrastil <michal.vrastil@hidglobal.com>
+Date: Wed, 13 Nov 2024 15:54:33 -0800
+Subject: Revert "usb: gadget: composite: fix OS descriptors w_value logic"
+
+From: Michal Vrastil <michal.vrastil@hidglobal.com>
+
+commit 51cdd69d6a857f527d6d0697a2e1f0fa8bca1005 upstream.
+
+This reverts commit ec6ce7075ef879b91a8710829016005dc8170f17.
+
+Fix installation of WinUSB driver using OS descriptors. Without the
+fix the drivers are not installed correctly and the property
+'DeviceInterfaceGUID' is missing on host side.
+
+The original change was based on the assumption that the interface
+number is in the high byte of wValue but it is in the low byte,
+instead. Unfortunately, the fix is based on MS documentation which is
+also wrong.
+
+The actual USB request for OS descriptors (using USB analyzer) looks
+like:
+
+Offset 0 1 2 3 4 5 6 7
+0x000 C1 A1 02 00 05 00 0A 00
+
+C1: bmRequestType (device to host, vendor, interface)
+A1: nas magic number
+0002: wValue (2: nas interface)
+0005: wIndex (5: get extended property i.e. nas interface GUID)
+008E: wLength (142)
+
+The fix was tested on Windows 10 and Windows 11.
+
+Cc: stable@vger.kernel.org
+Fixes: ec6ce7075ef8 ("usb: gadget: composite: fix OS descriptors w_value logic")
+Signed-off-by: Michal Vrastil <michal.vrastil@hidglobal.com>
+Signed-off-by: Elson Roy Serrao <quic_eserrao@quicinc.com>
+Acked-by: Peter korsgaard <peter@korsgaard.com>
+Link: https://lore.kernel.org/r/20241113235433.20244-1-quic_eserrao@quicinc.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/usb/gadget/composite.c | 18 +++++++++++++++---
+ 1 file changed, 15 insertions(+), 3 deletions(-)
+
+--- a/drivers/usb/gadget/composite.c
++++ b/drivers/usb/gadget/composite.c
+@@ -2111,8 +2111,20 @@ unknown:
+ memset(buf, 0, w_length);
+ buf[5] = 0x01;
+ switch (ctrl->bRequestType & USB_RECIP_MASK) {
++ /*
++ * The Microsoft CompatID OS Descriptor Spec(w_index = 0x4) and
++ * Extended Prop OS Desc Spec(w_index = 0x5) state that the
++ * HighByte of wValue is the InterfaceNumber and the LowByte is
++ * the PageNumber. This high/low byte ordering is incorrectly
++ * documented in the Spec. USB analyzer output on the below
++ * request packets show the high/low byte inverted i.e LowByte
++ * is the InterfaceNumber and the HighByte is the PageNumber.
++ * Since we dont support >64KB CompatID/ExtendedProp descriptors,
++ * PageNumber is set to 0. Hence verify that the HighByte is 0
++ * for below two cases.
++ */
+ case USB_RECIP_DEVICE:
+- if (w_index != 0x4 || (w_value & 0xff))
++ if (w_index != 0x4 || (w_value >> 8))
+ break;
+ buf[6] = w_index;
+ /* Number of ext compat interfaces */
+@@ -2128,9 +2140,9 @@ unknown:
+ }
+ break;
+ case USB_RECIP_INTERFACE:
+- if (w_index != 0x5 || (w_value & 0xff))
++ if (w_index != 0x5 || (w_value >> 8))
+ break;
+- interface = w_value >> 8;
++ interface = w_value & 0xFF;
+ if (interface >= MAX_CONFIG_INTERFACES ||
+ !os_desc_cfg->interface[interface])
+ break;
--- /dev/null
+From 3791ea69a4858b81e0277f695ca40f5aae40f312 Mon Sep 17 00:00:00 2001
+From: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
+Date: Wed, 6 Nov 2024 14:01:12 +0200
+Subject: serial: sh-sci: Clean sci_ports[0] after at earlycon exit
+
+From: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
+
+commit 3791ea69a4858b81e0277f695ca40f5aae40f312 upstream.
+
+The early_console_setup() function initializes the sci_ports[0].port with
+an object of type struct uart_port obtained from the object of type
+struct earlycon_device received as argument by the early_console_setup().
+
+It may happen that later, when the rest of the serial ports are probed,
+the serial port that was used as earlycon (e.g., port A) to be mapped to a
+different position in sci_ports[] and the slot 0 to be used by a different
+serial port (e.g., port B), as follows:
+
+sci_ports[0] = port A
+sci_ports[X] = port B
+
+In this case, the new port mapped at index zero will have associated data
+that was used for earlycon.
+
+In case this happens, after Linux boot, any access to the serial port that
+maps on sci_ports[0] (port A) will block the serial port that was used as
+earlycon (port B).
+
+To fix this, add early_console_exit() that clean the sci_ports[0] at
+earlycon exit time.
+
+Fixes: 0b0cced19ab1 ("serial: sh-sci: Add CONFIG_SERIAL_EARLYCON support")
+Cc: stable@vger.kernel.org
+Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
+Link: https://lore.kernel.org/r/20241106120118.1719888-4-claudiu.beznea.uj@bp.renesas.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/tty/serial/sh-sci.c | 28 ++++++++++++++++++++++++++++
+ 1 file changed, 28 insertions(+)
+
+--- a/drivers/tty/serial/sh-sci.c
++++ b/drivers/tty/serial/sh-sci.c
+@@ -3505,6 +3505,32 @@ sh_early_platform_init_buffer("earlyprin
+ #ifdef CONFIG_SERIAL_SH_SCI_EARLYCON
+ static struct plat_sci_port port_cfg __initdata;
+
++static int early_console_exit(struct console *co)
++{
++ struct sci_port *sci_port = &sci_ports[0];
++ struct uart_port *port = &sci_port->port;
++ unsigned long flags;
++ int locked = 1;
++
++ if (port->sysrq)
++ locked = 0;
++ else if (oops_in_progress)
++ locked = uart_port_trylock_irqsave(port, &flags);
++ else
++ uart_port_lock_irqsave(port, &flags);
++
++ /*
++ * Clean the slot used by earlycon. A new SCI device might
++ * map to this slot.
++ */
++ memset(sci_ports, 0, sizeof(*sci_port));
++
++ if (locked)
++ uart_port_unlock_irqrestore(port, flags);
++
++ return 0;
++}
++
+ static int __init early_console_setup(struct earlycon_device *device,
+ int type)
+ {
+@@ -3523,6 +3549,8 @@ static int __init early_console_setup(st
+ SCSCR_RE | SCSCR_TE | port_cfg.scscr);
+
+ device->con->write = serial_console_write;
++ device->con->exit = early_console_exit;
++
+ return 0;
+ }
+ static int __init sci_early_console_setup(struct earlycon_device *device,
bluetooth-fix-type-of-len-in-rfcomm_sock_getsockopt-_old.patch
compiler-attributes-disable-__counted_by-for-clang-19.1.3.patch
usb-xhci-fix-td-invalidation-under-pending-set-tr-dequeue.patch
+arm-dts-omap36xx-declare-1ghz-opp-as-turbo-again.patch
+wifi-ath12k-fix-warning-when-unbinding.patch
+wifi-rtlwifi-drastically-reduce-the-attempts-to-read-efuse-in-case-of-failures.patch
+wifi-ath12k-fix-crash-when-unbinding.patch
+wifi-brcmfmac-release-root-node-in-all-execution-paths.patch
+revert-usb-gadget-composite-fix-os-descriptors-w_value-logic.patch
+serial-sh-sci-clean-sci_ports-after-at-earlycon-exit.patch
+revert-serial-sh-sci-clean-sci_ports-after-at-earlycon-exit.patch
+gpio-exar-set-value-when-external-pull-up-or-pull-down-is-present.patch
+netfilter-ipset-add-missing-range-check-in-bitmap_ip_uadt.patch
+spi-fix-acpi-deferred-irq-probe.patch
+mtd-spi-nor-core-replace-dummy-buswidth-from-addr-to-data.patch
+cpufreq-mediatek-hw-fix-wrong-return-value-in-mtk_cpufreq_get_cpu_power.patch
+cifs-support-mounting-with-alternate-password-to-allow-password-rotation.patch
+parisc-ftrace-fix-function-graph-tracing-disablement.patch
+ksmbd-fix-use-after-free-in-smb-request-handling.patch
+smb-client-fix-null-ptr-deref-in-crypto_aead_setkey.patch
+platform-chrome-cros_ec_typec-fix-missing-fwnode-reference-decrement.patch
--- /dev/null
+From 4bdec0d1f658f7c98749bd2c5a486e6cfa8565d2 Mon Sep 17 00:00:00 2001
+From: Paulo Alcantara <pc@manguebit.com>
+Date: Mon, 25 Nov 2024 17:17:23 -0300
+Subject: smb: client: fix NULL ptr deref in crypto_aead_setkey()
+
+From: Paulo Alcantara <pc@manguebit.com>
+
+commit 4bdec0d1f658f7c98749bd2c5a486e6cfa8565d2 upstream.
+
+Neither SMB3.0 or SMB3.02 supports encryption negotiate context, so
+when SMB2_GLOBAL_CAP_ENCRYPTION flag is set in the negotiate response,
+the client uses AES-128-CCM as the default cipher. See MS-SMB2
+3.3.5.4.
+
+Commit b0abcd65ec54 ("smb: client: fix UAF in async decryption") added
+a @server->cipher_type check to conditionally call
+smb3_crypto_aead_allocate(), but that check would always be false as
+@server->cipher_type is unset for SMB3.02.
+
+Fix the following KASAN splat by setting @server->cipher_type for
+SMB3.02 as well.
+
+mount.cifs //srv/share /mnt -o vers=3.02,seal,...
+
+BUG: KASAN: null-ptr-deref in crypto_aead_setkey+0x2c/0x130
+Read of size 8 at addr 0000000000000020 by task mount.cifs/1095
+CPU: 1 UID: 0 PID: 1095 Comm: mount.cifs Not tainted 6.12.0 #1
+Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-3.fc41
+04/01/2014
+Call Trace:
+ <TASK>
+ dump_stack_lvl+0x5d/0x80
+ ? crypto_aead_setkey+0x2c/0x130
+ kasan_report+0xda/0x110
+ ? crypto_aead_setkey+0x2c/0x130
+ crypto_aead_setkey+0x2c/0x130
+ crypt_message+0x258/0xec0 [cifs]
+ ? __asan_memset+0x23/0x50
+ ? __pfx_crypt_message+0x10/0x10 [cifs]
+ ? mark_lock+0xb0/0x6a0
+ ? hlock_class+0x32/0xb0
+ ? mark_lock+0xb0/0x6a0
+ smb3_init_transform_rq+0x352/0x3f0 [cifs]
+ ? lock_acquire.part.0+0xf4/0x2a0
+ smb_send_rqst+0x144/0x230 [cifs]
+ ? __pfx_smb_send_rqst+0x10/0x10 [cifs]
+ ? hlock_class+0x32/0xb0
+ ? smb2_setup_request+0x225/0x3a0 [cifs]
+ ? __pfx_cifs_compound_last_callback+0x10/0x10 [cifs]
+ compound_send_recv+0x59b/0x1140 [cifs]
+ ? __pfx_compound_send_recv+0x10/0x10 [cifs]
+ ? __create_object+0x5e/0x90
+ ? hlock_class+0x32/0xb0
+ ? do_raw_spin_unlock+0x9a/0xf0
+ cifs_send_recv+0x23/0x30 [cifs]
+ SMB2_tcon+0x3ec/0xb30 [cifs]
+ ? __pfx_SMB2_tcon+0x10/0x10 [cifs]
+ ? lock_acquire.part.0+0xf4/0x2a0
+ ? __pfx_lock_release+0x10/0x10
+ ? do_raw_spin_trylock+0xc6/0x120
+ ? lock_acquire+0x3f/0x90
+ ? _get_xid+0x16/0xd0 [cifs]
+ ? __pfx_SMB2_tcon+0x10/0x10 [cifs]
+ ? cifs_get_smb_ses+0xcdd/0x10a0 [cifs]
+ cifs_get_smb_ses+0xcdd/0x10a0 [cifs]
+ ? __pfx_cifs_get_smb_ses+0x10/0x10 [cifs]
+ ? cifs_get_tcp_session+0xaa0/0xca0 [cifs]
+ cifs_mount_get_session+0x8a/0x210 [cifs]
+ dfs_mount_share+0x1b0/0x11d0 [cifs]
+ ? __pfx___lock_acquire+0x10/0x10
+ ? __pfx_dfs_mount_share+0x10/0x10 [cifs]
+ ? lock_acquire.part.0+0xf4/0x2a0
+ ? find_held_lock+0x8a/0xa0
+ ? hlock_class+0x32/0xb0
+ ? lock_release+0x203/0x5d0
+ cifs_mount+0xb3/0x3d0 [cifs]
+ ? do_raw_spin_trylock+0xc6/0x120
+ ? __pfx_cifs_mount+0x10/0x10 [cifs]
+ ? lock_acquire+0x3f/0x90
+ ? find_nls+0x16/0xa0
+ ? smb3_update_mnt_flags+0x372/0x3b0 [cifs]
+ cifs_smb3_do_mount+0x1e2/0xc80 [cifs]
+ ? __pfx_vfs_parse_fs_string+0x10/0x10
+ ? __pfx_cifs_smb3_do_mount+0x10/0x10 [cifs]
+ smb3_get_tree+0x1bf/0x330 [cifs]
+ vfs_get_tree+0x4a/0x160
+ path_mount+0x3c1/0xfb0
+ ? kasan_quarantine_put+0xc7/0x1d0
+ ? __pfx_path_mount+0x10/0x10
+ ? kmem_cache_free+0x118/0x3e0
+ ? user_path_at+0x74/0xa0
+ __x64_sys_mount+0x1a6/0x1e0
+ ? __pfx___x64_sys_mount+0x10/0x10
+ ? mark_held_locks+0x1a/0x90
+ do_syscall_64+0xbb/0x1d0
+ entry_SYSCALL_64_after_hwframe+0x77/0x7f
+
+Cc: Tom Talpey <tom@talpey.com>
+Reported-by: Jianhong Yin <jiyin@redhat.com>
+Cc: stable@vger.kernel.org # v6.12
+Fixes: b0abcd65ec54 ("smb: client: fix UAF in async decryption")
+Signed-off-by: Paulo Alcantara (Red Hat) <pc@manguebit.com>
+Signed-off-by: Steve French <stfrench@microsoft.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/smb/client/smb2pdu.c | 4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+--- a/fs/smb/client/smb2pdu.c
++++ b/fs/smb/client/smb2pdu.c
+@@ -1228,7 +1228,9 @@ SMB2_negotiate(const unsigned int xid,
+ * SMB3.0 supports only 1 cipher and doesn't have a encryption neg context
+ * Set the cipher type manually.
+ */
+- if (server->dialect == SMB30_PROT_ID && (server->capabilities & SMB2_GLOBAL_CAP_ENCRYPTION))
++ if ((server->dialect == SMB30_PROT_ID ||
++ server->dialect == SMB302_PROT_ID) &&
++ (server->capabilities & SMB2_GLOBAL_CAP_ENCRYPTION))
+ server->cipher_type = SMB2_ENCRYPTION_AES128_CCM;
+
+ security_blob = smb2_get_data_area_len(&blob_offset, &blob_length,
--- /dev/null
+From d24cfee7f63d6b44d45a67c5662bd1cc48e8b3ca Mon Sep 17 00:00:00 2001
+From: Stanislaw Gruszka <stanislaw.gruszka@linux.intel.com>
+Date: Fri, 22 Nov 2024 10:42:24 +0100
+Subject: spi: Fix acpi deferred irq probe
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Stanislaw Gruszka <stanislaw.gruszka@linux.intel.com>
+
+commit d24cfee7f63d6b44d45a67c5662bd1cc48e8b3ca upstream.
+
+When probing spi device take care of deferred probe of ACPI irq gpio
+similar like for OF/DT case.
+
+>From practical standpoint this fixes issue with vsc-tp driver on
+Dell XP 9340 laptop, which try to request interrupt with spi->irq
+equal to -EPROBE_DEFER and fail to probe with the following error:
+
+vsc-tp spi-INTC10D0:00: probe with driver vsc-tp failed with error -22
+
+Suggested-by: Hans de Goede <hdegoede@redhat.com>
+Fixes: 33ada67da352 ("ACPI / spi: attach GPIO IRQ from ACPI description to SPI device")
+Cc: stable@vger.kernel.org
+Signed-off-by: Stanislaw Gruszka <stanislaw.gruszka@linux.intel.com>
+Reviewed-by: Hans de Goede <hdegoede@redhat.com>
+Tested-by: Alexis Lothoré <alexis.lothore@bootlin.com> # Dell XPS9320, ov01a10
+Link: https://patch.msgid.link/20241122094224.226773-1-stanislaw.gruszka@linux.intel.com
+Signed-off-by: Mark Brown <broonie@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/spi/spi.c | 13 ++++++++++---
+ 1 file changed, 10 insertions(+), 3 deletions(-)
+
+--- a/drivers/spi/spi.c
++++ b/drivers/spi/spi.c
+@@ -426,6 +426,16 @@ static int spi_probe(struct device *dev)
+ spi->irq = 0;
+ }
+
++ if (has_acpi_companion(dev) && spi->irq < 0) {
++ struct acpi_device *adev = to_acpi_device_node(dev->fwnode);
++
++ spi->irq = acpi_dev_gpio_irq_get(adev, 0);
++ if (spi->irq == -EPROBE_DEFER)
++ return -EPROBE_DEFER;
++ if (spi->irq < 0)
++ spi->irq = 0;
++ }
++
+ ret = dev_pm_domain_attach(dev, true);
+ if (ret)
+ return ret;
+@@ -2706,9 +2716,6 @@ static acpi_status acpi_register_spi_dev
+ acpi_set_modalias(adev, acpi_device_hid(adev), spi->modalias,
+ sizeof(spi->modalias));
+
+- if (spi->irq < 0)
+- spi->irq = acpi_dev_gpio_irq_get(adev, 0);
+-
+ acpi_device_set_enumerated(adev);
+
+ adev->power.flags.ignore_parent = true;
--- /dev/null
+From 1304446f67863385dc4c914b6e0194f6664ee764 Mon Sep 17 00:00:00 2001
+From: Jose Ignacio Tornos Martinez <jtornosm@redhat.com>
+Date: Thu, 17 Oct 2024 20:07:31 +0200
+Subject: wifi: ath12k: fix crash when unbinding
+
+From: Jose Ignacio Tornos Martinez <jtornosm@redhat.com>
+
+commit 1304446f67863385dc4c914b6e0194f6664ee764 upstream.
+
+If there is an error during some initialization related to firmware,
+the function ath12k_dp_cc_cleanup is called to release resources.
+However this is released again when the device is unbinded (ath12k_pci),
+and we get:
+BUG: kernel NULL pointer dereference, address: 0000000000000020
+at RIP: 0010:ath12k_dp_cc_cleanup.part.0+0xb6/0x500 [ath12k]
+Call Trace:
+ath12k_dp_cc_cleanup
+ath12k_dp_free
+ath12k_core_deinit
+ath12k_pci_remove
+...
+
+The issue is always reproducible from a VM because the MSI addressing
+initialization is failing.
+
+In order to fix the issue, just set to NULL the released structure in
+ath12k_dp_cc_cleanup at the end.
+
+cc: stable@vger.kernel.org
+Fixes: d889913205cf ("wifi: ath12k: driver for Qualcomm Wi-Fi 7 devices")
+Signed-off-by: Jose Ignacio Tornos Martinez <jtornosm@redhat.com>
+Link: https://patch.msgid.link/20241017181004.199589-2-jtornosm@redhat.com
+Signed-off-by: Jeff Johnson <quic_jjohnson@quicinc.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/wireless/ath/ath12k/dp.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/net/wireless/ath/ath12k/dp.c
++++ b/drivers/net/wireless/ath/ath12k/dp.c
+@@ -1214,6 +1214,7 @@ static void ath12k_dp_cc_cleanup(struct
+ }
+
+ kfree(dp->spt_info);
++ dp->spt_info = NULL;
+ }
+
+ static void ath12k_dp_reoq_lut_cleanup(struct ath12k_base *ab)
--- /dev/null
+From ca68ce0d9f4bcd032fd1334441175ae399642a06 Mon Sep 17 00:00:00 2001
+From: Jose Ignacio Tornos Martinez <jtornosm@redhat.com>
+Date: Thu, 17 Oct 2024 20:07:32 +0200
+Subject: wifi: ath12k: fix warning when unbinding
+
+From: Jose Ignacio Tornos Martinez <jtornosm@redhat.com>
+
+commit ca68ce0d9f4bcd032fd1334441175ae399642a06 upstream.
+
+If there is an error during some initialization related to firmware,
+the buffers dp->tx_ring[i].tx_status are released.
+However this is released again when the device is unbinded (ath12k_pci),
+and we get:
+WARNING: CPU: 0 PID: 2098 at mm/slub.c:4689 free_large_kmalloc+0x4d/0x80
+Call Trace:
+free_large_kmalloc
+ath12k_dp_free
+ath12k_core_deinit
+ath12k_pci_remove
+...
+
+The issue is always reproducible from a VM because the MSI addressing
+initialization is failing.
+
+In order to fix the issue, just set the buffers to NULL after releasing in
+order to avoid the double free.
+
+cc: stable@vger.kernel.org
+Fixes: d889913205cf ("wifi: ath12k: driver for Qualcomm Wi-Fi 7 devices")
+Signed-off-by: Jose Ignacio Tornos Martinez <jtornosm@redhat.com>
+Link: https://patch.msgid.link/20241017181004.199589-3-jtornosm@redhat.com
+Signed-off-by: Jeff Johnson <quic_jjohnson@quicinc.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/wireless/ath/ath12k/dp.c | 4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+--- a/drivers/net/wireless/ath/ath12k/dp.c
++++ b/drivers/net/wireless/ath/ath12k/dp.c
+@@ -1249,8 +1249,10 @@ void ath12k_dp_free(struct ath12k_base *
+
+ ath12k_dp_rx_reo_cmd_list_cleanup(ab);
+
+- for (i = 0; i < ab->hw_params->max_tx_ring; i++)
++ for (i = 0; i < ab->hw_params->max_tx_ring; i++) {
+ kfree(dp->tx_ring[i].tx_status);
++ dp->tx_ring[i].tx_status = NULL;
++ }
+
+ ath12k_dp_rx_free(ab);
+ /* Deinit any SOC level resource */
--- /dev/null
+From 2e19a3b590ebf2e351fc9d0e7c323430e65b6b6d Mon Sep 17 00:00:00 2001
+From: Javier Carrasco <javier.carrasco.cruz@gmail.com>
+Date: Wed, 30 Oct 2024 18:34:45 +0100
+Subject: wifi: brcmfmac: release 'root' node in all execution paths
+
+From: Javier Carrasco <javier.carrasco.cruz@gmail.com>
+
+commit 2e19a3b590ebf2e351fc9d0e7c323430e65b6b6d upstream.
+
+The fixed patch introduced an additional condition to enter the scope
+where the 'root' device_node is released (!settings->board_type,
+currently 'err'), which avoid decrementing the refcount with a call to
+of_node_put() if that second condition is not satisfied.
+
+Move the call to of_node_put() to the point where 'root' is no longer
+required to avoid leaking the resource if err is not zero.
+
+Cc: stable@vger.kernel.org
+Fixes: 7682de8b3351 ("wifi: brcmfmac: of: Fetch Apple properties")
+Signed-off-by: Javier Carrasco <javier.carrasco.cruz@gmail.com>
+Signed-off-by: Kalle Valo <kvalo@kernel.org>
+Link: https://patch.msgid.link/20241030-brcmfmac-of-cleanup-v1-1-0b90eefb4279@gmail.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/wireless/broadcom/brcm80211/brcmfmac/of.c | 3 +--
+ 1 file changed, 1 insertion(+), 2 deletions(-)
+
+--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/of.c
++++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/of.c
+@@ -109,9 +109,8 @@ void brcmf_of_probe(struct device *dev,
+ }
+ strreplace(board_type, '/', '-');
+ settings->board_type = board_type;
+-
+- of_node_put(root);
+ }
++ of_node_put(root);
+
+ if (!np || !of_device_is_compatible(np, "brcm,bcm4329-fmac"))
+ return;
--- /dev/null
+From 5c1b544563005a00591a3aa86ecff62ed4d11be3 Mon Sep 17 00:00:00 2001
+From: "Guilherme G. Piccoli" <gpiccoli@igalia.com>
+Date: Fri, 1 Nov 2024 16:30:05 -0300
+Subject: wifi: rtlwifi: Drastically reduce the attempts to read efuse in case of failures
+
+From: Guilherme G. Piccoli <gpiccoli@igalia.com>
+
+commit 5c1b544563005a00591a3aa86ecff62ed4d11be3 upstream.
+
+Syzkaller reported a hung task with uevent_show() on stack trace. That
+specific issue was addressed by another commit [0], but even with that
+fix applied (for example, running v6.12-rc5) we face another type of hung
+task that comes from the same reproducer [1]. By investigating that, we
+could narrow it to the following path:
+
+(a) Syzkaller emulates a Realtek USB WiFi adapter using raw-gadget and
+dummy_hcd infrastructure.
+
+(b) During the probe of rtl8192cu, the driver ends-up performing an efuse
+read procedure (which is related to EEPROM load IIUC), and here lies the
+issue: the function read_efuse() calls read_efuse_byte() many times, as
+loop iterations depending on the efuse size (in our example, 512 in total).
+
+This procedure for reading efuse bytes relies in a loop that performs an
+I/O read up to *10k* times in case of failures. We measured the time of
+the loop inside read_efuse_byte() alone, and in this reproducer (which
+involves the dummy_hcd emulation layer), it takes 15 seconds each. As a
+consequence, we have the driver stuck in its probe routine for big time,
+exposing a stack trace like below if we attempt to reboot the system, for
+example:
+
+task:kworker/0:3 state:D stack:0 pid:662 tgid:662 ppid:2 flags:0x00004000
+Workqueue: usb_hub_wq hub_event
+Call Trace:
+ __schedule+0xe22/0xeb6
+ schedule_timeout+0xe7/0x132
+ __wait_for_common+0xb5/0x12e
+ usb_start_wait_urb+0xc5/0x1ef
+ ? usb_alloc_urb+0x95/0xa4
+ usb_control_msg+0xff/0x184
+ _usbctrl_vendorreq_sync+0xa0/0x161
+ _usb_read_sync+0xb3/0xc5
+ read_efuse_byte+0x13c/0x146
+ read_efuse+0x351/0x5f0
+ efuse_read_all_map+0x42/0x52
+ rtl_efuse_shadow_map_update+0x60/0xef
+ rtl_get_hwinfo+0x5d/0x1c2
+ rtl92cu_read_eeprom_info+0x10a/0x8d5
+ ? rtl92c_read_chip_version+0x14f/0x17e
+ rtl_usb_probe+0x323/0x851
+ usb_probe_interface+0x278/0x34b
+ really_probe+0x202/0x4a4
+ __driver_probe_device+0x166/0x1b2
+ driver_probe_device+0x2f/0xd8
+ [...]
+
+We propose hereby to drastically reduce the attempts of doing the I/O
+reads in case of failures, restricted to USB devices (given that
+they're inherently slower than PCIe ones). By retrying up to 10 times
+(instead of 10000), we got reponsiveness in the reproducer, while seems
+reasonable to believe that there's no sane USB device implementation in
+the field requiring this amount of retries at every I/O read in order
+to properly work. Based on that assumption, it'd be good to have it
+backported to stable but maybe not since driver implementation (the 10k
+number comes from day 0), perhaps up to 6.x series makes sense.
+
+[0] Commit 15fffc6a5624 ("driver core: Fix uevent_show() vs driver detach race")
+
+[1] A note about that: this syzkaller report presents multiple reproducers
+that differs by the type of emulated USB device. For this specific case,
+check the entry from 2024/08/08 06:23 in the list of crashes; the C repro
+is available at https://syzkaller.appspot.com/text?tag=ReproC&x=1521fc83980000.
+
+Cc: stable@vger.kernel.org # v6.1+
+Reported-by: syzbot+edd9fe0d3a65b14588d5@syzkaller.appspotmail.com
+Tested-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
+Signed-off-by: Guilherme G. Piccoli <gpiccoli@igalia.com>
+Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
+Link: https://patch.msgid.link/20241101193412.1390391-1-gpiccoli@igalia.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/wireless/realtek/rtlwifi/efuse.c | 11 ++++++++++-
+ 1 file changed, 10 insertions(+), 1 deletion(-)
+
+--- a/drivers/net/wireless/realtek/rtlwifi/efuse.c
++++ b/drivers/net/wireless/realtek/rtlwifi/efuse.c
+@@ -162,10 +162,19 @@ void efuse_write_1byte(struct ieee80211_
+ void read_efuse_byte(struct ieee80211_hw *hw, u16 _offset, u8 *pbuf)
+ {
+ struct rtl_priv *rtlpriv = rtl_priv(hw);
++ u16 max_attempts = 10000;
+ u32 value32;
+ u8 readbyte;
+ u16 retry;
+
++ /*
++ * In case of USB devices, transfer speeds are limited, hence
++ * efuse I/O reads could be (way) slower. So, decrease (a lot)
++ * the read attempts in case of failures.
++ */
++ if (rtlpriv->rtlhal.interface == INTF_USB)
++ max_attempts = 10;
++
+ rtl_write_byte(rtlpriv, rtlpriv->cfg->maps[EFUSE_CTRL] + 1,
+ (_offset & 0xff));
+ readbyte = rtl_read_byte(rtlpriv, rtlpriv->cfg->maps[EFUSE_CTRL] + 2);
+@@ -178,7 +187,7 @@ void read_efuse_byte(struct ieee80211_hw
+
+ retry = 0;
+ value32 = rtl_read_dword(rtlpriv, rtlpriv->cfg->maps[EFUSE_CTRL]);
+- while (!(((value32 >> 24) & 0xff) & 0x80) && (retry < 10000)) {
++ while (!(((value32 >> 24) & 0xff) & 0x80) && (retry < max_attempts)) {
+ value32 = rtl_read_dword(rtlpriv,
+ rtlpriv->cfg->maps[EFUSE_CTRL]);
+ retry++;
projects / thirdparty / kernel / stable-queue.git / commitdiff
