From: Greg Kroah-Hartman Date: Mon, 30 Dec 2024 08:31:10 +0000 (+0100) Subject: 6.6-stable patches X-Git-Tag: v6.1.123~19 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=8695175e545369360f8c3fe5f5d42fdc1a63e2cf;p=thirdparty%2Fkernel%2Fstable-queue.git 6.6-stable patches added patches: i2c-imx-add-imx7d-compatible-string-for-applying-erratum-err007805.patch i2c-microchip-core-actually-use-repeated-sends.patch i2c-microchip-core-fix-ghost-detections.patch io_uring-sqpoll-fix-sqpoll-error-handling-races.patch pci-msi-handle-lack-of-irqdomain-gracefully.patch power-supply-gpio-charger-fix-set-charge-current-limits.patch tracing-constify-string-literal-data-member-in-struct-trace_event_call.patch tracing-prevent-bad-count-for-tracing_cpumask_write.patch x86-fred-clear-wfe-in-missing-endbranch-cps.patch --- diff --git a/queue-6.6/i2c-imx-add-imx7d-compatible-string-for-applying-erratum-err007805.patch b/queue-6.6/i2c-imx-add-imx7d-compatible-string-for-applying-erratum-err007805.patch new file mode 100644 index 00000000000..1ed41128450 --- /dev/null +++ b/queue-6.6/i2c-imx-add-imx7d-compatible-string-for-applying-erratum-err007805.patch @@ -0,0 +1,59 @@ +From e0cec363197e41af870613e8e17b30bf0e3d41b5 Mon Sep 17 00:00:00 2001 +From: Carlos Song +Date: Wed, 18 Dec 2024 12:42:38 +0800 +Subject: i2c: imx: add imx7d compatible string for applying erratum ERR007805 + +From: Carlos Song + +commit e0cec363197e41af870613e8e17b30bf0e3d41b5 upstream. + +Compatible string "fsl,imx7d-i2c" is not exited at i2c-imx driver +compatible string table, at the result, "fsl,imx21-i2c" will be +matched, but it will cause erratum ERR007805 not be applied in fact. + +So Add "fsl,imx7d-i2c" compatible string in i2c-imx driver to apply +the erratum ERR007805(https://www.nxp.com/docs/en/errata/IMX7DS_3N09P.pdf). + +" +ERR007805 I2C: When the I2C clock speed is configured for 400 kHz, +the SCL low period violates the I2C spec of 1.3 uS min + +Description: When the I2C module is programmed to operate at the +maximum clock speed of 400 kHz (as defined by the I2C spec), the SCL +clock low period violates the I2C spec of 1.3 uS min. The user must +reduce the clock speed to obtain the SCL low time to meet the 1.3us +I2C minimum required. This behavior means the SoC is not compliant +to the I2C spec at 400kHz. + +Workaround: To meet the clock low period requirement in fast speed +mode, SCL must be configured to 384KHz or less. +" + +"fsl,imx7d-i2c" already is documented in binding doc. This erratum +fix has been included in imx6_i2c_hwdata and it is the same in all +I.MX6/7/8, so just reuse it. + +Fixes: 39c025721d70 ("i2c: imx: Implement errata ERR007805 or e7805 bus frequency limit") +Cc: stable@vger.kernel.org # v5.18+ +Signed-off-by: Carlos Song +Signed-off-by: Haibo Chen +Reviewed-by: Frank Li +Fixes: 39c025721d70 ("i2c: imx: Implement errata ERR007805 or e7805 bus frequency limit") +Acked-by: Oleksij Rempel +Link: https://lore.kernel.org/r/20241218044238.143414-1-carlos.song@nxp.com +Signed-off-by: Andi Shyti +Signed-off-by: Greg Kroah-Hartman +--- + drivers/i2c/busses/i2c-imx.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/drivers/i2c/busses/i2c-imx.c ++++ b/drivers/i2c/busses/i2c-imx.c +@@ -286,6 +286,7 @@ static const struct of_device_id i2c_imx + { .compatible = "fsl,imx6sll-i2c", .data = &imx6_i2c_hwdata, }, + { .compatible = "fsl,imx6sx-i2c", .data = &imx6_i2c_hwdata, }, + { .compatible = "fsl,imx6ul-i2c", .data = &imx6_i2c_hwdata, }, ++ { .compatible = "fsl,imx7d-i2c", .data = &imx6_i2c_hwdata, }, + { .compatible = "fsl,imx7s-i2c", .data = &imx6_i2c_hwdata, }, + { .compatible = "fsl,imx8mm-i2c", .data = &imx6_i2c_hwdata, }, + { .compatible = "fsl,imx8mn-i2c", .data = &imx6_i2c_hwdata, }, diff --git a/queue-6.6/i2c-microchip-core-actually-use-repeated-sends.patch b/queue-6.6/i2c-microchip-core-actually-use-repeated-sends.patch new file mode 100644 index 00000000000..d866fe82da7 --- /dev/null +++ b/queue-6.6/i2c-microchip-core-actually-use-repeated-sends.patch @@ -0,0 +1,220 @@ +From 9a8f9320d67b27ddd7f1ee88d91820197a0e908f Mon Sep 17 00:00:00 2001 +From: Conor Dooley +Date: Wed, 18 Dec 2024 12:07:40 +0000 +Subject: i2c: microchip-core: actually use repeated sends + +From: Conor Dooley + +commit 9a8f9320d67b27ddd7f1ee88d91820197a0e908f upstream. + +At present, where repeated sends are intended to be used, the +i2c-microchip-core driver sends a stop followed by a start. Lots of i2c +devices must not malfunction in the face of this behaviour, because the +driver has operated like this for years! Try to keep track of whether or +not a repeated send is required, and suppress sending a stop in these +cases. + +CC: stable@vger.kernel.org +Fixes: 64a6f1c4987e ("i2c: add support for microchip fpga i2c controllers") +Signed-off-by: Conor Dooley +Reviewed-by: Andi Shyti +Link: https://lore.kernel.org/r/20241218-football-composure-e56df2461461@spud +Signed-off-by: Andi Shyti +Signed-off-by: Greg Kroah-Hartman +--- + drivers/i2c/busses/i2c-microchip-corei2c.c | 120 ++++++++++++++++++++++------- + 1 file changed, 94 insertions(+), 26 deletions(-) + +--- a/drivers/i2c/busses/i2c-microchip-corei2c.c ++++ b/drivers/i2c/busses/i2c-microchip-corei2c.c +@@ -93,27 +93,35 @@ + * @base: pointer to register struct + * @dev: device reference + * @i2c_clk: clock reference for i2c input clock ++ * @msg_queue: pointer to the messages requiring sending + * @buf: pointer to msg buffer for easier use + * @msg_complete: xfer completion object + * @adapter: core i2c abstraction + * @msg_err: error code for completed message + * @bus_clk_rate: current i2c bus clock rate + * @isr_status: cached copy of local ISR status ++ * @total_num: total number of messages to be sent/received ++ * @current_num: index of the current message being sent/received + * @msg_len: number of bytes transferred in msg + * @addr: address of the current slave ++ * @restart_needed: whether or not a repeated start is required after current message + */ + struct mchp_corei2c_dev { + void __iomem *base; + struct device *dev; + struct clk *i2c_clk; ++ struct i2c_msg *msg_queue; + u8 *buf; + struct completion msg_complete; + struct i2c_adapter adapter; + int msg_err; ++ int total_num; ++ int current_num; + u32 bus_clk_rate; + u32 isr_status; + u16 msg_len; + u8 addr; ++ bool restart_needed; + }; + + static void mchp_corei2c_core_disable(struct mchp_corei2c_dev *idev) +@@ -222,6 +230,47 @@ static int mchp_corei2c_fill_tx(struct m + return 0; + } + ++static void mchp_corei2c_next_msg(struct mchp_corei2c_dev *idev) ++{ ++ struct i2c_msg *this_msg; ++ u8 ctrl; ++ ++ if (idev->current_num >= idev->total_num) { ++ complete(&idev->msg_complete); ++ return; ++ } ++ ++ /* ++ * If there's been an error, the isr needs to return control ++ * to the "main" part of the driver, so as not to keep sending ++ * messages once it completes and clears the SI bit. ++ */ ++ if (idev->msg_err) { ++ complete(&idev->msg_complete); ++ return; ++ } ++ ++ this_msg = idev->msg_queue++; ++ ++ if (idev->current_num < (idev->total_num - 1)) { ++ struct i2c_msg *next_msg = idev->msg_queue; ++ ++ idev->restart_needed = next_msg->flags & I2C_M_RD; ++ } else { ++ idev->restart_needed = false; ++ } ++ ++ idev->addr = i2c_8bit_addr_from_msg(this_msg); ++ idev->msg_len = this_msg->len; ++ idev->buf = this_msg->buf; ++ ++ ctrl = readb(idev->base + CORE_I2C_CTRL); ++ ctrl |= CTRL_STA; ++ writeb(ctrl, idev->base + CORE_I2C_CTRL); ++ ++ idev->current_num++; ++} ++ + static irqreturn_t mchp_corei2c_handle_isr(struct mchp_corei2c_dev *idev) + { + u32 status = idev->isr_status; +@@ -247,10 +296,14 @@ static irqreturn_t mchp_corei2c_handle_i + break; + case STATUS_M_SLAW_ACK: + case STATUS_M_TX_DATA_ACK: +- if (idev->msg_len > 0) ++ if (idev->msg_len > 0) { + mchp_corei2c_fill_tx(idev); +- else +- last_byte = true; ++ } else { ++ if (idev->restart_needed) ++ finished = true; ++ else ++ last_byte = true; ++ } + break; + case STATUS_M_TX_DATA_NACK: + case STATUS_M_SLAR_NACK: +@@ -287,7 +340,7 @@ static irqreturn_t mchp_corei2c_handle_i + mchp_corei2c_stop(idev); + + if (last_byte || finished) +- complete(&idev->msg_complete); ++ mchp_corei2c_next_msg(idev); + + return IRQ_HANDLED; + } +@@ -311,21 +364,48 @@ static irqreturn_t mchp_corei2c_isr(int + return ret; + } + +-static int mchp_corei2c_xfer_msg(struct mchp_corei2c_dev *idev, +- struct i2c_msg *msg) ++static int mchp_corei2c_xfer(struct i2c_adapter *adap, struct i2c_msg *msgs, ++ int num) + { +- u8 ctrl; ++ struct mchp_corei2c_dev *idev = i2c_get_adapdata(adap); ++ struct i2c_msg *this_msg = msgs; + unsigned long time_left; ++ u8 ctrl; + +- idev->addr = i2c_8bit_addr_from_msg(msg); +- idev->msg_len = msg->len; +- idev->buf = msg->buf; ++ mchp_corei2c_core_enable(idev); ++ ++ /* ++ * The isr controls the flow of a transfer, this info needs to be saved ++ * to a location that it can access the queue information from. ++ */ ++ idev->restart_needed = false; ++ idev->msg_queue = msgs; ++ idev->total_num = num; ++ idev->current_num = 0; ++ ++ /* ++ * But the first entry to the isr is triggered by the start in this ++ * function, so the first message needs to be "dequeued". ++ */ ++ idev->addr = i2c_8bit_addr_from_msg(this_msg); ++ idev->msg_len = this_msg->len; ++ idev->buf = this_msg->buf; + idev->msg_err = 0; + +- reinit_completion(&idev->msg_complete); ++ if (idev->total_num > 1) { ++ struct i2c_msg *next_msg = msgs + 1; + +- mchp_corei2c_core_enable(idev); ++ idev->restart_needed = next_msg->flags & I2C_M_RD; ++ } + ++ idev->current_num++; ++ idev->msg_queue++; ++ ++ reinit_completion(&idev->msg_complete); ++ ++ /* ++ * Send the first start to pass control to the isr ++ */ + ctrl = readb(idev->base + CORE_I2C_CTRL); + ctrl |= CTRL_STA; + writeb(ctrl, idev->base + CORE_I2C_CTRL); +@@ -335,20 +415,8 @@ static int mchp_corei2c_xfer_msg(struct + if (!time_left) + return -ETIMEDOUT; + +- return idev->msg_err; +-} +- +-static int mchp_corei2c_xfer(struct i2c_adapter *adap, struct i2c_msg *msgs, +- int num) +-{ +- struct mchp_corei2c_dev *idev = i2c_get_adapdata(adap); +- int i, ret; +- +- for (i = 0; i < num; i++) { +- ret = mchp_corei2c_xfer_msg(idev, msgs++); +- if (ret) +- return ret; +- } ++ if (idev->msg_err) ++ return idev->msg_err; + + return num; + } diff --git a/queue-6.6/i2c-microchip-core-fix-ghost-detections.patch b/queue-6.6/i2c-microchip-core-fix-ghost-detections.patch new file mode 100644 index 00000000000..fb8d1bcf870 --- /dev/null +++ b/queue-6.6/i2c-microchip-core-fix-ghost-detections.patch @@ -0,0 +1,51 @@ +From 49e1f0fd0d4cb03a16b8526c4e683e1958f71490 Mon Sep 17 00:00:00 2001 +From: Conor Dooley +Date: Wed, 18 Dec 2024 12:07:42 +0000 +Subject: i2c: microchip-core: fix "ghost" detections + +From: Conor Dooley + +commit 49e1f0fd0d4cb03a16b8526c4e683e1958f71490 upstream. + +Running i2c-detect currently produces an output akin to: + 0 1 2 3 4 5 6 7 8 9 a b c d e f +00: 08 -- 0a -- 0c -- 0e -- +10: 10 -- 12 -- 14 -- 16 -- UU 19 -- 1b -- 1d -- 1f +20: -- 21 -- 23 -- 25 -- 27 -- 29 -- 2b -- 2d -- 2f +30: -- -- -- -- -- -- -- -- 38 -- 3a -- 3c -- 3e -- +40: 40 -- 42 -- 44 -- 46 -- 48 -- 4a -- 4c -- 4e -- +50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- +60: 60 -- 62 -- 64 -- 66 -- 68 -- 6a -- 6c -- 6e -- +70: 70 -- 72 -- 74 -- 76 -- + +This happens because for an i2c_msg with a len of 0 the driver will +mark the transmission of the message as a success once the START has +been sent, without waiting for the devices on the bus to respond with an +ACK/NAK. Since i2cdetect seems to run in a tight loop over all addresses +the NAK is treated as part of the next test for the next address. + +Delete the fast path that marks a message as complete when idev->msg_len +is zero after sending a START/RESTART since this isn't a valid scenario. + +CC: stable@vger.kernel.org +Fixes: 64a6f1c4987e ("i2c: add support for microchip fpga i2c controllers") +Signed-off-by: Conor Dooley +Reviewed-by: Andi Shyti +Link: https://lore.kernel.org/r/20241218-outbid-encounter-b2e78b1cc707@spud +Signed-off-by: Andi Shyti +Signed-off-by: Greg Kroah-Hartman +--- + drivers/i2c/busses/i2c-microchip-corei2c.c | 2 -- + 1 file changed, 2 deletions(-) + +--- a/drivers/i2c/busses/i2c-microchip-corei2c.c ++++ b/drivers/i2c/busses/i2c-microchip-corei2c.c +@@ -287,8 +287,6 @@ static irqreturn_t mchp_corei2c_handle_i + ctrl &= ~CTRL_STA; + writeb(idev->addr, idev->base + CORE_I2C_DATA); + writeb(ctrl, idev->base + CORE_I2C_CTRL); +- if (idev->msg_len == 0) +- finished = true; + break; + case STATUS_M_ARB_LOST: + idev->msg_err = -EAGAIN; diff --git a/queue-6.6/io_uring-sqpoll-fix-sqpoll-error-handling-races.patch b/queue-6.6/io_uring-sqpoll-fix-sqpoll-error-handling-races.patch new file mode 100644 index 00000000000..a27c6c27bc0 --- /dev/null +++ b/queue-6.6/io_uring-sqpoll-fix-sqpoll-error-handling-races.patch @@ -0,0 +1,75 @@ +From e33ac68e5e21ec1292490dfe061e75c0dbdd3bd4 Mon Sep 17 00:00:00 2001 +From: Pavel Begunkov +Date: Thu, 26 Dec 2024 16:49:23 +0000 +Subject: io_uring/sqpoll: fix sqpoll error handling races + +From: Pavel Begunkov + +commit e33ac68e5e21ec1292490dfe061e75c0dbdd3bd4 upstream. + +BUG: KASAN: slab-use-after-free in __lock_acquire+0x370b/0x4a10 kernel/locking/lockdep.c:5089 +Call Trace: + +... +_raw_spin_lock_irqsave+0x3d/0x60 kernel/locking/spinlock.c:162 +class_raw_spinlock_irqsave_constructor include/linux/spinlock.h:551 [inline] +try_to_wake_up+0xb5/0x23c0 kernel/sched/core.c:4205 +io_sq_thread_park+0xac/0xe0 io_uring/sqpoll.c:55 +io_sq_thread_finish+0x6b/0x310 io_uring/sqpoll.c:96 +io_sq_offload_create+0x162/0x11d0 io_uring/sqpoll.c:497 +io_uring_create io_uring/io_uring.c:3724 [inline] +io_uring_setup+0x1728/0x3230 io_uring/io_uring.c:3806 +... + +Kun Hu reports that the SQPOLL creating error path has UAF, which +happens if io_uring_alloc_task_context() fails and then io_sq_thread() +manages to run and complete before the rest of error handling code, +which means io_sq_thread_finish() is looking at already killed task. + +Note that this is mostly theoretical, requiring fault injection on +the allocation side to trigger in practice. + +Cc: stable@vger.kernel.org +Reported-by: Kun Hu +Signed-off-by: Pavel Begunkov +Link: https://lore.kernel.org/r/0f2f1aa5729332612bd01fe0f2f385fd1f06ce7c.1735231717.git.asml.silence@gmail.com +Signed-off-by: Jens Axboe +Signed-off-by: Greg Kroah-Hartman +--- + io_uring/sqpoll.c | 6 ++++++ + 1 file changed, 6 insertions(+) + +--- a/io_uring/sqpoll.c ++++ b/io_uring/sqpoll.c +@@ -352,6 +352,7 @@ void io_sqpoll_wait_sq(struct io_ring_ct + __cold int io_sq_offload_create(struct io_ring_ctx *ctx, + struct io_uring_params *p) + { ++ struct task_struct *task_to_put = NULL; + int ret; + + /* Retain compatibility with failing for an invalid attach attempt */ +@@ -432,6 +433,7 @@ __cold int io_sq_offload_create(struct i + } + + sqd->thread = tsk; ++ task_to_put = get_task_struct(tsk); + ret = io_uring_alloc_task_context(tsk, ctx); + wake_up_new_task(tsk); + if (ret) +@@ -442,11 +444,15 @@ __cold int io_sq_offload_create(struct i + goto err; + } + ++ if (task_to_put) ++ put_task_struct(task_to_put); + return 0; + err_sqpoll: + complete(&ctx->sq_data->exited); + err: + io_sq_thread_finish(ctx); ++ if (task_to_put) ++ put_task_struct(task_to_put); + return ret; + } + diff --git a/queue-6.6/pci-msi-handle-lack-of-irqdomain-gracefully.patch b/queue-6.6/pci-msi-handle-lack-of-irqdomain-gracefully.patch new file mode 100644 index 00000000000..50f6c876a1e --- /dev/null +++ b/queue-6.6/pci-msi-handle-lack-of-irqdomain-gracefully.patch @@ -0,0 +1,74 @@ +From a60b990798eb17433d0283788280422b1bd94b18 Mon Sep 17 00:00:00 2001 +From: Thomas Gleixner +Date: Sat, 14 Dec 2024 12:50:18 +0100 +Subject: PCI/MSI: Handle lack of irqdomain gracefully + +From: Thomas Gleixner + +commit a60b990798eb17433d0283788280422b1bd94b18 upstream. + +Alexandre observed a warning emitted from pci_msi_setup_msi_irqs() on a +RISCV platform which does not provide PCI/MSI support: + + WARNING: CPU: 1 PID: 1 at drivers/pci/msi/msi.h:121 pci_msi_setup_msi_irqs+0x2c/0x32 + __pci_enable_msix_range+0x30c/0x596 + pci_msi_setup_msi_irqs+0x2c/0x32 + pci_alloc_irq_vectors_affinity+0xb8/0xe2 + +RISCV uses hierarchical interrupt domains and correctly does not implement +the legacy fallback. The warning triggers from the legacy fallback stub. + +That warning is bogus as the PCI/MSI layer knows whether a PCI/MSI parent +domain is associated with the device or not. There is a check for MSI-X, +which has a legacy assumption. But that legacy fallback assumption is only +valid when legacy support is enabled, but otherwise the check should simply +return -ENOTSUPP. + +Loongarch tripped over the same problem and blindly enabled legacy support +without implementing the legacy fallbacks. There are weak implementations +which return an error, so the problem was papered over. + +Correct pci_msi_domain_supports() to evaluate the legacy mode and add +the missing supported check into the MSI enable path to complete it. + +Fixes: d2a463b29741 ("PCI/MSI: Reject multi-MSI early") +Reported-by: Alexandre Ghiti +Signed-off-by: Thomas Gleixner +Tested-by: Alexandre Ghiti +Cc: stable@vger.kernel.org +Link: https://lore.kernel.org/all/87ed2a8ow5.ffs@tglx +Signed-off-by: Greg Kroah-Hartman +--- + drivers/pci/msi/irqdomain.c | 7 +++++-- + drivers/pci/msi/msi.c | 4 ++++ + 2 files changed, 9 insertions(+), 2 deletions(-) + +--- a/drivers/pci/msi/irqdomain.c ++++ b/drivers/pci/msi/irqdomain.c +@@ -330,8 +330,11 @@ bool pci_msi_domain_supports(struct pci_ + + domain = dev_get_msi_domain(&pdev->dev); + +- if (!domain || !irq_domain_is_hierarchy(domain)) +- return mode == ALLOW_LEGACY; ++ if (!domain || !irq_domain_is_hierarchy(domain)) { ++ if (IS_ENABLED(CONFIG_PCI_MSI_ARCH_FALLBACKS)) ++ return mode == ALLOW_LEGACY; ++ return false; ++ } + + if (!irq_domain_is_msi_parent(domain)) { + /* +--- a/drivers/pci/msi/msi.c ++++ b/drivers/pci/msi/msi.c +@@ -429,6 +429,10 @@ int __pci_enable_msi_range(struct pci_de + if (WARN_ON_ONCE(dev->msi_enabled)) + return -EINVAL; + ++ /* Test for the availability of MSI support */ ++ if (!pci_msi_domain_supports(dev, 0, ALLOW_LEGACY)) ++ return -ENOTSUPP; ++ + nvec = pci_msi_vec_count(dev); + if (nvec < 0) + return nvec; diff --git a/queue-6.6/power-supply-gpio-charger-fix-set-charge-current-limits.patch b/queue-6.6/power-supply-gpio-charger-fix-set-charge-current-limits.patch new file mode 100644 index 00000000000..ccfe0b8c56f --- /dev/null +++ b/queue-6.6/power-supply-gpio-charger-fix-set-charge-current-limits.patch @@ -0,0 +1,41 @@ +From afc6e39e824ad0e44b2af50a97885caec8d213d1 Mon Sep 17 00:00:00 2001 +From: Dimitri Fedrau +Date: Mon, 9 Dec 2024 11:46:15 +0100 +Subject: power: supply: gpio-charger: Fix set charge current limits + +From: Dimitri Fedrau + +commit afc6e39e824ad0e44b2af50a97885caec8d213d1 upstream. + +Fix set charge current limits for devices which allow to set the lowest +charge current limit to be greater zero. If requested charge current limit +is below lowest limit, the index equals current_limit_map_size which leads +to accessing memory beyond allocated memory. + +Fixes: be2919d8355e ("power: supply: gpio-charger: add charge-current-limit feature") +Cc: stable@vger.kernel.org +Signed-off-by: Dimitri Fedrau +Link: https://lore.kernel.org/r/20241209-fix-charge-current-limit-v1-1-760d9b8f2af3@liebherr.com +Signed-off-by: Sebastian Reichel +Signed-off-by: Greg Kroah-Hartman +--- + drivers/power/supply/gpio-charger.c | 8 ++++++++ + 1 file changed, 8 insertions(+) + +--- a/drivers/power/supply/gpio-charger.c ++++ b/drivers/power/supply/gpio-charger.c +@@ -67,6 +67,14 @@ static int set_charge_current_limit(stru + if (gpio_charger->current_limit_map[i].limit_ua <= val) + break; + } ++ ++ /* ++ * If a valid charge current limit isn't found, default to smallest ++ * current limitation for safety reasons. ++ */ ++ if (i >= gpio_charger->current_limit_map_size) ++ i = gpio_charger->current_limit_map_size - 1; ++ + mapping = gpio_charger->current_limit_map[i]; + + for (i = 0; i < ndescs; i++) { diff --git a/queue-6.6/series b/queue-6.6/series index f539584845c..b102a6f36dd 100644 --- a/queue-6.6/series +++ b/queue-6.6/series @@ -70,3 +70,12 @@ drm-amdkfd-drop-struct-kfd_cu_info.patch drm-amdkfd-use-device-based-logging-for-errors.patch drm-amdkfd-pause-autosuspend-when-creating-pdd.patch freezer-sched-report-frozen-tasks-as-d-instead-of-r.patch +tracing-constify-string-literal-data-member-in-struct-trace_event_call.patch +tracing-prevent-bad-count-for-tracing_cpumask_write.patch +io_uring-sqpoll-fix-sqpoll-error-handling-races.patch +i2c-microchip-core-actually-use-repeated-sends.patch +x86-fred-clear-wfe-in-missing-endbranch-cps.patch +pci-msi-handle-lack-of-irqdomain-gracefully.patch +i2c-imx-add-imx7d-compatible-string-for-applying-erratum-err007805.patch +i2c-microchip-core-fix-ghost-detections.patch +power-supply-gpio-charger-fix-set-charge-current-limits.patch diff --git a/queue-6.6/tracing-constify-string-literal-data-member-in-struct-trace_event_call.patch b/queue-6.6/tracing-constify-string-literal-data-member-in-struct-trace_event_call.patch new file mode 100644 index 00000000000..47fe3000f24 --- /dev/null +++ b/queue-6.6/tracing-constify-string-literal-data-member-in-struct-trace_event_call.patch @@ -0,0 +1,66 @@ +From 452f4b31e3f70a52b97890888eeb9eaa9a87139a Mon Sep 17 00:00:00 2001 +From: =?UTF-8?q?Christian=20G=C3=B6ttsche?= +Date: Mon, 25 Nov 2024 11:50:25 +0100 +Subject: tracing: Constify string literal data member in struct trace_event_call +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Christian Göttsche + +commit 452f4b31e3f70a52b97890888eeb9eaa9a87139a upstream. + +The name member of the struct trace_event_call is assigned with +generated string literals; declare them pointer to read-only. + +Reported by clang: + + security/landlock/syscalls.c:179:1: warning: initializing 'char *' with an expression of type 'const char[34]' discards qualifiers [-Wincompatible-pointer-types-discards-qualifiers] + 179 | SYSCALL_DEFINE3(landlock_create_ruleset, + | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + 180 | const struct landlock_ruleset_attr __user *const, attr, + | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + 181 | const size_t, size, const __u32, flags) + | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + ./include/linux/syscalls.h:226:36: note: expanded from macro 'SYSCALL_DEFINE3' + 226 | #define SYSCALL_DEFINE3(name, ...) SYSCALL_DEFINEx(3, _##name, __VA_ARGS__) + | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + ./include/linux/syscalls.h:234:2: note: expanded from macro 'SYSCALL_DEFINEx' + 234 | SYSCALL_METADATA(sname, x, __VA_ARGS__) \ + | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + ./include/linux/syscalls.h:184:2: note: expanded from macro 'SYSCALL_METADATA' + 184 | SYSCALL_TRACE_ENTER_EVENT(sname); \ + | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + ./include/linux/syscalls.h:151:30: note: expanded from macro 'SYSCALL_TRACE_ENTER_EVENT' + 151 | .name = "sys_enter"#sname, \ + | ^~~~~~~~~~~~~~~~~ + +Cc: stable@vger.kernel.org +Cc: Masami Hiramatsu +Cc: Mathieu Desnoyers +Cc: Mickaël Salaün +Cc: Günther Noack +Cc: Nathan Chancellor +Cc: Nick Desaulniers +Cc: Bill Wendling +Cc: Justin Stitt +Link: https://lore.kernel.org/20241125105028.42807-1-cgoettsche@seltendoof.de +Fixes: b77e38aa240c3 ("tracing: add event trace infrastructure") +Signed-off-by: Christian Göttsche +Signed-off-by: Steven Rostedt (Google) +Signed-off-by: Greg Kroah-Hartman +--- + include/linux/trace_events.h | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/include/linux/trace_events.h ++++ b/include/linux/trace_events.h +@@ -369,7 +369,7 @@ struct trace_event_call { + struct list_head list; + struct trace_event_class *class; + union { +- char *name; ++ const char *name; + /* Set TRACE_EVENT_FL_TRACEPOINT flag when using "tp" */ + struct tracepoint *tp; + }; diff --git a/queue-6.6/tracing-prevent-bad-count-for-tracing_cpumask_write.patch b/queue-6.6/tracing-prevent-bad-count-for-tracing_cpumask_write.patch new file mode 100644 index 00000000000..10cadbcb383 --- /dev/null +++ b/queue-6.6/tracing-prevent-bad-count-for-tracing_cpumask_write.patch @@ -0,0 +1,37 @@ +From 98feccbf32cfdde8c722bc4587aaa60ee5ac33f0 Mon Sep 17 00:00:00 2001 +From: Lizhi Xu +Date: Mon, 16 Dec 2024 15:32:38 +0800 +Subject: tracing: Prevent bad count for tracing_cpumask_write + +From: Lizhi Xu + +commit 98feccbf32cfdde8c722bc4587aaa60ee5ac33f0 upstream. + +If a large count is provided, it will trigger a warning in bitmap_parse_user. +Also check zero for it. + +Cc: stable@vger.kernel.org +Fixes: 9e01c1b74c953 ("cpumask: convert kernel trace functions") +Link: https://lore.kernel.org/20241216073238.2573704-1-lizhi.xu@windriver.com +Reported-by: syzbot+0aecfd34fb878546f3fd@syzkaller.appspotmail.com +Closes: https://syzkaller.appspot.com/bug?extid=0aecfd34fb878546f3fd +Tested-by: syzbot+0aecfd34fb878546f3fd@syzkaller.appspotmail.com +Signed-off-by: Lizhi Xu +Signed-off-by: Steven Rostedt (Google) +Signed-off-by: Greg Kroah-Hartman +--- + kernel/trace/trace.c | 3 +++ + 1 file changed, 3 insertions(+) + +--- a/kernel/trace/trace.c ++++ b/kernel/trace/trace.c +@@ -5331,6 +5331,9 @@ tracing_cpumask_write(struct file *filp, + cpumask_var_t tracing_cpumask_new; + int err; + ++ if (count == 0 || count > KMALLOC_MAX_SIZE) ++ return -EINVAL; ++ + if (!zalloc_cpumask_var(&tracing_cpumask_new, GFP_KERNEL)) + return -ENOMEM; + diff --git a/queue-6.6/x86-fred-clear-wfe-in-missing-endbranch-cps.patch b/queue-6.6/x86-fred-clear-wfe-in-missing-endbranch-cps.patch new file mode 100644 index 00000000000..8a9a737f273 --- /dev/null +++ b/queue-6.6/x86-fred-clear-wfe-in-missing-endbranch-cps.patch @@ -0,0 +1,103 @@ +From dc81e556f2a017d681251ace21bf06c126d5a192 Mon Sep 17 00:00:00 2001 +From: "Xin Li (Intel)" +Date: Wed, 13 Nov 2024 09:59:34 -0800 +Subject: x86/fred: Clear WFE in missing-ENDBRANCH #CPs + +From: Xin Li (Intel) + +commit dc81e556f2a017d681251ace21bf06c126d5a192 upstream. + +An indirect branch instruction sets the CPU indirect branch tracker +(IBT) into WAIT_FOR_ENDBRANCH (WFE) state and WFE stays asserted +across the instruction boundary. When the decoder finds an +inappropriate instruction while WFE is set ENDBR, the CPU raises a #CP +fault. + +For the "kernel IBT no ENDBR" selftest where #CPs are deliberately +triggered, the WFE state of the interrupted context needs to be +cleared to let execution continue. Otherwise when the CPU resumes +from the instruction that just caused the previous #CP, another +missing-ENDBRANCH #CP is raised and the CPU enters a dead loop. + +This is not a problem with IDT because it doesn't preserve WFE and +IRET doesn't set WFE. But FRED provides space on the entry stack +(in an expanded CS area) to save and restore the WFE state, thus the +WFE state is no longer clobbered, so software must clear it. + +Clear WFE to avoid dead looping in ibt_clear_fred_wfe() and the +!ibt_fatal code path when execution is allowed to continue. + +Clobbering WFE in any other circumstance is a security-relevant bug. + +[ dhansen: changelog rewording ] + +Fixes: a5f6c2ace997 ("x86/shstk: Add user control-protection fault handler") +Signed-off-by: Xin Li (Intel) +Signed-off-by: Dave Hansen +Signed-off-by: Ingo Molnar +Acked-by: Dave Hansen +Cc: stable@vger.kernel.org +Link: https://lore.kernel.org/all/20241113175934.3897541-1-xin%40zytor.com +Signed-off-by: Greg Kroah-Hartman +--- + arch/x86/kernel/cet.c | 30 ++++++++++++++++++++++++++++++ + 1 file changed, 30 insertions(+) + +diff --git a/arch/x86/kernel/cet.c b/arch/x86/kernel/cet.c +index d2c732a34e5d..303bf74d175b 100644 +--- a/arch/x86/kernel/cet.c ++++ b/arch/x86/kernel/cet.c +@@ -81,6 +81,34 @@ static void do_user_cp_fault(struct pt_regs *regs, unsigned long error_code) + + static __ro_after_init bool ibt_fatal = true; + ++/* ++ * By definition, all missing-ENDBRANCH #CPs are a result of WFE && !ENDBR. ++ * ++ * For the kernel IBT no ENDBR selftest where #CPs are deliberately triggered, ++ * the WFE state of the interrupted context needs to be cleared to let execution ++ * continue. Otherwise when the CPU resumes from the instruction that just ++ * caused the previous #CP, another missing-ENDBRANCH #CP is raised and the CPU ++ * enters a dead loop. ++ * ++ * This is not a problem with IDT because it doesn't preserve WFE and IRET doesn't ++ * set WFE. But FRED provides space on the entry stack (in an expanded CS area) ++ * to save and restore the WFE state, thus the WFE state is no longer clobbered, ++ * so software must clear it. ++ */ ++static void ibt_clear_fred_wfe(struct pt_regs *regs) ++{ ++ /* ++ * No need to do any FRED checks. ++ * ++ * For IDT event delivery, the high-order 48 bits of CS are pushed ++ * as 0s into the stack, and later IRET ignores these bits. ++ * ++ * For FRED, a test to check if fred_cs.wfe is set would be dropped ++ * by compilers. ++ */ ++ regs->fred_cs.wfe = 0; ++} ++ + static void do_kernel_cp_fault(struct pt_regs *regs, unsigned long error_code) + { + if ((error_code & CP_EC) != CP_ENDBR) { +@@ -90,6 +118,7 @@ static void do_kernel_cp_fault(struct pt_regs *regs, unsigned long error_code) + + if (unlikely(regs->ip == (unsigned long)&ibt_selftest_noendbr)) { + regs->ax = 0; ++ ibt_clear_fred_wfe(regs); + return; + } + +@@ -97,6 +126,7 @@ static void do_kernel_cp_fault(struct pt_regs *regs, unsigned long error_code) + if (!ibt_fatal) { + printk(KERN_DEFAULT CUT_HERE); + __warn(__FILE__, __LINE__, (void *)regs->ip, TAINT_WARN, regs, NULL); ++ ibt_clear_fred_wfe(regs); + return; + } + BUG(); +-- +2.47.1 +