From: Greg Kroah-Hartman Date: Tue, 3 Dec 2024 09:59:38 +0000 (+0100) Subject: 6.6-stable patches X-Git-Tag: v4.19.325~55 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=d26adf9029080db21bbe6a0dc7c93c3a5b9cd150;p=thirdparty%2Fkernel%2Fstable-queue.git 6.6-stable patches added patches: arm-dts-omap36xx-declare-1ghz-opp-as-turbo-again.patch cifs-support-mounting-with-alternate-password-to-allow-password-rotation.patch cpufreq-mediatek-hw-fix-wrong-return-value-in-mtk_cpufreq_get_cpu_power.patch gpio-exar-set-value-when-external-pull-up-or-pull-down-is-present.patch ksmbd-fix-use-after-free-in-smb-request-handling.patch mtd-spi-nor-core-replace-dummy-buswidth-from-addr-to-data.patch netfilter-ipset-add-missing-range-check-in-bitmap_ip_uadt.patch parisc-ftrace-fix-function-graph-tracing-disablement.patch platform-chrome-cros_ec_typec-fix-missing-fwnode-reference-decrement.patch revert-serial-sh-sci-clean-sci_ports-after-at-earlycon-exit.patch revert-usb-gadget-composite-fix-os-descriptors-w_value-logic.patch serial-sh-sci-clean-sci_ports-after-at-earlycon-exit.patch smb-client-fix-null-ptr-deref-in-crypto_aead_setkey.patch spi-fix-acpi-deferred-irq-probe.patch wifi-ath12k-fix-crash-when-unbinding.patch wifi-ath12k-fix-warning-when-unbinding.patch wifi-brcmfmac-release-root-node-in-all-execution-paths.patch wifi-rtlwifi-drastically-reduce-the-attempts-to-read-efuse-in-case-of-failures.patch --- diff --git a/queue-6.6/arm-dts-omap36xx-declare-1ghz-opp-as-turbo-again.patch b/queue-6.6/arm-dts-omap36xx-declare-1ghz-opp-as-turbo-again.patch new file mode 100644 index 00000000000..3cec9226038 --- /dev/null +++ b/queue-6.6/arm-dts-omap36xx-declare-1ghz-opp-as-turbo-again.patch @@ -0,0 +1,46 @@ +From 96a64e9730c2c76cfa5c510583a0fbf40d62886b Mon Sep 17 00:00:00 2001 +From: Andreas Kemnade +Date: Fri, 18 Oct 2024 23:47:27 +0200 +Subject: ARM: dts: omap36xx: declare 1GHz OPP as turbo again + +From: Andreas Kemnade + +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 +Link: https://lore.kernel.org/r/20241018214727.275162-1-andreas@kemnade.info +Signed-off-by: Kevin Hilman +Signed-off-by: Greg Kroah-Hartman +--- + 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; + }; + }; + diff --git a/queue-6.6/cifs-support-mounting-with-alternate-password-to-allow-password-rotation.patch b/queue-6.6/cifs-support-mounting-with-alternate-password-to-allow-password-rotation.patch new file mode 100644 index 00000000000..4a6ad2fdda1 --- /dev/null +++ b/queue-6.6/cifs-support-mounting-with-alternate-password-to-allow-password-rotation.patch @@ -0,0 +1,139 @@ +From b9aef1b13a0a92aa7058ba235afb24b5b89153ca Mon Sep 17 00:00:00 2001 +From: Meetakshi Setiya +Date: Wed, 30 Oct 2024 05:37:21 -0400 +Subject: cifs: support mounting with alternate password to allow password rotation + +From: Meetakshi Setiya + +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 +Signed-off-by: Steve French +Signed-off-by: Greg Kroah-Hartman +--- + 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 diff --git a/queue-6.6/cpufreq-mediatek-hw-fix-wrong-return-value-in-mtk_cpufreq_get_cpu_power.patch b/queue-6.6/cpufreq-mediatek-hw-fix-wrong-return-value-in-mtk_cpufreq_get_cpu_power.patch new file mode 100644 index 00000000000..2b146d22820 --- /dev/null +++ b/queue-6.6/cpufreq-mediatek-hw-fix-wrong-return-value-in-mtk_cpufreq_get_cpu_power.patch @@ -0,0 +1,36 @@ +From 172bf5ed04cb6c9e66d58de003938ed5c8756570 Mon Sep 17 00:00:00 2001 +From: Jinjie Ruan +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 + +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 +Suggested-by: Lukasz Luba +Signed-off-by: Jinjie Ruan +Signed-off-by: Viresh Kumar +Signed-off-by: Greg Kroah-Hartman +--- + 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; + diff --git a/queue-6.6/gpio-exar-set-value-when-external-pull-up-or-pull-down-is-present.patch b/queue-6.6/gpio-exar-set-value-when-external-pull-up-or-pull-down-is-present.patch new file mode 100644 index 00000000000..640bd2ac683 --- /dev/null +++ b/queue-6.6/gpio-exar-set-value-when-external-pull-up-or-pull-down-is-present.patch @@ -0,0 +1,78 @@ +From 72cef64180de04a7b055b4773c138d78f4ebdb77 Mon Sep 17 00:00:00 2001 +From: Sai Kumar Cholleti +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 + +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 +Signed-off-by: Matthew McClain +Signed-off-by: Sai Kumar Cholleti +Cc: stable@vger.kernel.org +Reviewed-by: Andy Shevchenko +Link: https://lore.kernel.org/r/20241105071523.2372032-1-skmr537@gmail.com +Signed-off-by: Bartosz Golaszewski +Signed-off-by: Greg Kroah-Hartman +--- + 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, diff --git a/queue-6.6/ksmbd-fix-use-after-free-in-smb-request-handling.patch b/queue-6.6/ksmbd-fix-use-after-free-in-smb-request-handling.patch new file mode 100644 index 00000000000..e6268209cc5 --- /dev/null +++ b/queue-6.6/ksmbd-fix-use-after-free-in-smb-request-handling.patch @@ -0,0 +1,62 @@ +From 9a8c5d89d327ff58e9b2517f8a6afb4181d32c6e Mon Sep 17 00:00:00 2001 +From: Yunseong Kim +Date: Mon, 25 Nov 2024 16:45:55 +0900 +Subject: ksmbd: fix use-after-free in SMB request handling + +From: Yunseong Kim + +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 +Acked-by: Namjae Jeon +Signed-off-by: Steve French +Signed-off-by: Greg Kroah-Hartman +--- + 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 + diff --git a/queue-6.6/mtd-spi-nor-core-replace-dummy-buswidth-from-addr-to-data.patch b/queue-6.6/mtd-spi-nor-core-replace-dummy-buswidth-from-addr-to-data.patch new file mode 100644 index 00000000000..3c172a34a22 --- /dev/null +++ b/queue-6.6/mtd-spi-nor-core-replace-dummy-buswidth-from-addr-to-data.patch @@ -0,0 +1,44 @@ +From 98d1fb94ce75f39febd456d6d3cbbe58b6678795 Mon Sep 17 00:00:00 2001 +From: Cheng Ming Lin +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 + +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 +Signed-off-by: Cheng Ming Lin +Link: https://lore.kernel.org/r/20241112075242.174010-2-linchengming884@gmail.com +Signed-off-by: Tudor Ambarus +Signed-off-by: Greg Kroah-Hartman +--- + 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); diff --git a/queue-6.6/netfilter-ipset-add-missing-range-check-in-bitmap_ip_uadt.patch b/queue-6.6/netfilter-ipset-add-missing-range-check-in-bitmap_ip_uadt.patch new file mode 100644 index 00000000000..949c81c755e --- /dev/null +++ b/queue-6.6/netfilter-ipset-add-missing-range-check-in-bitmap_ip_uadt.patch @@ -0,0 +1,51 @@ +From 35f56c554eb1b56b77b3cf197a6b00922d49033d Mon Sep 17 00:00:00 2001 +From: Jeongjun Park +Date: Wed, 13 Nov 2024 22:02:09 +0900 +Subject: netfilter: ipset: add missing range check in bitmap_ip_uadt + +From: Jeongjun Park + +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: +Reported-by: syzbot+58c872f7790a4d2ac951@syzkaller.appspotmail.com +Fixes: 72205fc68bd1 ("netfilter: ipset: bitmap:ip set type support") +Signed-off-by: Jeongjun Park +Acked-by: Jozsef Kadlecsik +Signed-off-by: Pablo Neira Ayuso +Signed-off-by: Greg Kroah-Hartman +--- + 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) { diff --git a/queue-6.6/parisc-ftrace-fix-function-graph-tracing-disablement.patch b/queue-6.6/parisc-ftrace-fix-function-graph-tracing-disablement.patch new file mode 100644 index 00000000000..e93c6028bbb --- /dev/null +++ b/queue-6.6/parisc-ftrace-fix-function-graph-tracing-disablement.patch @@ -0,0 +1,37 @@ +From a5f05a138a8cac035bf9da9b6ed0e532bc7942c8 Mon Sep 17 00:00:00 2001 +From: Josh Poimboeuf +Date: Wed, 2 Oct 2024 14:32:04 -0700 +Subject: parisc/ftrace: Fix function graph tracing disablement + +From: Josh Poimboeuf + +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 +Signed-off-by: Helge Deller +Signed-off-by: Greg Kroah-Hartman +--- + 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 diff --git a/queue-6.6/platform-chrome-cros_ec_typec-fix-missing-fwnode-reference-decrement.patch b/queue-6.6/platform-chrome-cros_ec_typec-fix-missing-fwnode-reference-decrement.patch new file mode 100644 index 00000000000..cd6bb372fda --- /dev/null +++ b/queue-6.6/platform-chrome-cros_ec_typec-fix-missing-fwnode-reference-decrement.patch @@ -0,0 +1,36 @@ +From 9c41f371457bd9a24874e3c7934d9745e87fbc58 Mon Sep 17 00:00:00 2001 +From: Javier Carrasco +Date: Sun, 13 Oct 2024 15:20:24 +0200 +Subject: platform/chrome: cros_ec_typec: fix missing fwnode reference decrement + +From: Javier Carrasco + +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 +Link: https://lore.kernel.org/r/20241013-cross_ec_typec_fwnode_handle_put-v2-1-9182b2cd7767@gmail.com +Signed-off-by: Tzung-Bi Shih +Signed-off-by: Greg Kroah-Hartman +--- + 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; + } diff --git a/queue-6.6/revert-serial-sh-sci-clean-sci_ports-after-at-earlycon-exit.patch b/queue-6.6/revert-serial-sh-sci-clean-sci_ports-after-at-earlycon-exit.patch new file mode 100644 index 00000000000..82a32a371df --- /dev/null +++ b/queue-6.6/revert-serial-sh-sci-clean-sci_ports-after-at-earlycon-exit.patch @@ -0,0 +1,66 @@ +From 718632467d88e98816fa01ab12681ef1c2aa56f8 Mon Sep 17 00:00:00 2001 +From: Greg Kroah-Hartman +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 + +commit 718632467d88e98816fa01ab12681ef1c2aa56f8 upstream. + +This reverts commit 3791ea69a4858b81e0277f695ca40f5aae40f312. + +It was reported to cause boot-time issues, so revert it for now. + +Reported-by: Geert Uytterhoeven +Fixes: 3791ea69a485 ("serial: sh-sci: Clean sci_ports[0] after at earlycon exit") +Cc: stable +Cc: Claudiu Beznea +Signed-off-by: Greg Kroah-Hartman +--- + 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, diff --git a/queue-6.6/revert-usb-gadget-composite-fix-os-descriptors-w_value-logic.patch b/queue-6.6/revert-usb-gadget-composite-fix-os-descriptors-w_value-logic.patch new file mode 100644 index 00000000000..267ca8fe2df --- /dev/null +++ b/queue-6.6/revert-usb-gadget-composite-fix-os-descriptors-w_value-logic.patch @@ -0,0 +1,81 @@ +From 51cdd69d6a857f527d6d0697a2e1f0fa8bca1005 Mon Sep 17 00:00:00 2001 +From: Michal Vrastil +Date: Wed, 13 Nov 2024 15:54:33 -0800 +Subject: Revert "usb: gadget: composite: fix OS descriptors w_value logic" + +From: Michal Vrastil + +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 +Signed-off-by: Elson Roy Serrao +Acked-by: Peter korsgaard +Link: https://lore.kernel.org/r/20241113235433.20244-1-quic_eserrao@quicinc.com +Signed-off-by: Greg Kroah-Hartman +--- + 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; diff --git a/queue-6.6/serial-sh-sci-clean-sci_ports-after-at-earlycon-exit.patch b/queue-6.6/serial-sh-sci-clean-sci_ports-after-at-earlycon-exit.patch new file mode 100644 index 00000000000..9c80636b21c --- /dev/null +++ b/queue-6.6/serial-sh-sci-clean-sci_ports-after-at-earlycon-exit.patch @@ -0,0 +1,84 @@ +From 3791ea69a4858b81e0277f695ca40f5aae40f312 Mon Sep 17 00:00:00 2001 +From: Claudiu Beznea +Date: Wed, 6 Nov 2024 14:01:12 +0200 +Subject: serial: sh-sci: Clean sci_ports[0] after at earlycon exit + +From: Claudiu Beznea + +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 +Link: https://lore.kernel.org/r/20241106120118.1719888-4-claudiu.beznea.uj@bp.renesas.com +Signed-off-by: Greg Kroah-Hartman +--- + 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, diff --git a/queue-6.6/series b/queue-6.6/series index a4c667c2873..c1e803f7ff4 100644 --- a/queue-6.6/series +++ b/queue-6.6/series @@ -502,3 +502,21 @@ exfat-fix-uninit-value-in-__exfat_get_dentry_set.patch 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 diff --git a/queue-6.6/smb-client-fix-null-ptr-deref-in-crypto_aead_setkey.patch b/queue-6.6/smb-client-fix-null-ptr-deref-in-crypto_aead_setkey.patch new file mode 100644 index 00000000000..1fabd878329 --- /dev/null +++ b/queue-6.6/smb-client-fix-null-ptr-deref-in-crypto_aead_setkey.patch @@ -0,0 +1,121 @@ +From 4bdec0d1f658f7c98749bd2c5a486e6cfa8565d2 Mon Sep 17 00:00:00 2001 +From: Paulo Alcantara +Date: Mon, 25 Nov 2024 17:17:23 -0300 +Subject: smb: client: fix NULL ptr deref in crypto_aead_setkey() + +From: Paulo Alcantara + +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: + + 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 +Reported-by: Jianhong Yin +Cc: stable@vger.kernel.org # v6.12 +Fixes: b0abcd65ec54 ("smb: client: fix UAF in async decryption") +Signed-off-by: Paulo Alcantara (Red Hat) +Signed-off-by: Steve French +Signed-off-by: Greg Kroah-Hartman +--- + 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, diff --git a/queue-6.6/spi-fix-acpi-deferred-irq-probe.patch b/queue-6.6/spi-fix-acpi-deferred-irq-probe.patch new file mode 100644 index 00000000000..454c5de4b4f --- /dev/null +++ b/queue-6.6/spi-fix-acpi-deferred-irq-probe.patch @@ -0,0 +1,63 @@ +From d24cfee7f63d6b44d45a67c5662bd1cc48e8b3ca Mon Sep 17 00:00:00 2001 +From: Stanislaw Gruszka +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 + +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 +Fixes: 33ada67da352 ("ACPI / spi: attach GPIO IRQ from ACPI description to SPI device") +Cc: stable@vger.kernel.org +Signed-off-by: Stanislaw Gruszka +Reviewed-by: Hans de Goede +Tested-by: Alexis Lothoré # Dell XPS9320, ov01a10 +Link: https://patch.msgid.link/20241122094224.226773-1-stanislaw.gruszka@linux.intel.com +Signed-off-by: Mark Brown +Signed-off-by: Greg Kroah-Hartman +--- + 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; diff --git a/queue-6.6/wifi-ath12k-fix-crash-when-unbinding.patch b/queue-6.6/wifi-ath12k-fix-crash-when-unbinding.patch new file mode 100644 index 00000000000..35b31acf753 --- /dev/null +++ b/queue-6.6/wifi-ath12k-fix-crash-when-unbinding.patch @@ -0,0 +1,48 @@ +From 1304446f67863385dc4c914b6e0194f6664ee764 Mon Sep 17 00:00:00 2001 +From: Jose Ignacio Tornos Martinez +Date: Thu, 17 Oct 2024 20:07:31 +0200 +Subject: wifi: ath12k: fix crash when unbinding + +From: Jose Ignacio Tornos Martinez + +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 +Link: https://patch.msgid.link/20241017181004.199589-2-jtornosm@redhat.com +Signed-off-by: Jeff Johnson +Signed-off-by: Greg Kroah-Hartman +--- + 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) diff --git a/queue-6.6/wifi-ath12k-fix-warning-when-unbinding.patch b/queue-6.6/wifi-ath12k-fix-warning-when-unbinding.patch new file mode 100644 index 00000000000..2e894afeac2 --- /dev/null +++ b/queue-6.6/wifi-ath12k-fix-warning-when-unbinding.patch @@ -0,0 +1,51 @@ +From ca68ce0d9f4bcd032fd1334441175ae399642a06 Mon Sep 17 00:00:00 2001 +From: Jose Ignacio Tornos Martinez +Date: Thu, 17 Oct 2024 20:07:32 +0200 +Subject: wifi: ath12k: fix warning when unbinding + +From: Jose Ignacio Tornos Martinez + +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 +Link: https://patch.msgid.link/20241017181004.199589-3-jtornosm@redhat.com +Signed-off-by: Jeff Johnson +Signed-off-by: Greg Kroah-Hartman +--- + 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 */ diff --git a/queue-6.6/wifi-brcmfmac-release-root-node-in-all-execution-paths.patch b/queue-6.6/wifi-brcmfmac-release-root-node-in-all-execution-paths.patch new file mode 100644 index 00000000000..01431de3a20 --- /dev/null +++ b/queue-6.6/wifi-brcmfmac-release-root-node-in-all-execution-paths.patch @@ -0,0 +1,40 @@ +From 2e19a3b590ebf2e351fc9d0e7c323430e65b6b6d Mon Sep 17 00:00:00 2001 +From: Javier Carrasco +Date: Wed, 30 Oct 2024 18:34:45 +0100 +Subject: wifi: brcmfmac: release 'root' node in all execution paths + +From: Javier Carrasco + +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 +Signed-off-by: Kalle Valo +Link: https://patch.msgid.link/20241030-brcmfmac-of-cleanup-v1-1-0b90eefb4279@gmail.com +Signed-off-by: Greg Kroah-Hartman +--- + 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; diff --git a/queue-6.6/wifi-rtlwifi-drastically-reduce-the-attempts-to-read-efuse-in-case-of-failures.patch b/queue-6.6/wifi-rtlwifi-drastically-reduce-the-attempts-to-read-efuse-in-case-of-failures.patch new file mode 100644 index 00000000000..8cd41593911 --- /dev/null +++ b/queue-6.6/wifi-rtlwifi-drastically-reduce-the-attempts-to-read-efuse-in-case-of-failures.patch @@ -0,0 +1,115 @@ +From 5c1b544563005a00591a3aa86ecff62ed4d11be3 Mon Sep 17 00:00:00 2001 +From: "Guilherme G. Piccoli" +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 + +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 +Signed-off-by: Guilherme G. Piccoli +Signed-off-by: Ping-Ke Shih +Link: https://patch.msgid.link/20241101193412.1390391-1-gpiccoli@igalia.com +Signed-off-by: Greg Kroah-Hartman +--- + 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++;