From: Greg Kroah-Hartman Date: Thu, 16 Oct 2025 13:17:57 +0000 (+0200) Subject: 5.10-stable patches X-Git-Tag: v5.15.195~69 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=c33bbcfda87c31940b817d3bf0c3a5cd95fd4bd3;p=thirdparty%2Fkernel%2Fstable-queue.git 5.10-stable patches added patches: lib-genalloc-fix-device-leak-in-of_gen_pool_get.patch memory-samsung-exynos-srom-fix-of_iomap-leak-in-exynos_srom_probe.patch mmc-core-spi-mode-remove-cmd7.patch mtd-rawnand-fsmc-default-to-autodetect-buswidth.patch openat2-don-t-trigger-automounts-with-resolve_no_xdev.patch parisc-don-t-reference-obsolete-termio-struct-for-tc-constants.patch pci-aer-fix-missing-uevent-on-recovery-when-a-reset-is-requested.patch pci-aer-support-errors-introduced-by-pcie-r6.0.patch pci-err-fix-uevent-on-failure-to-recover.patch pci-iov-add-pci-rescan-remove-locking-when-enabling-disabling-sr-iov.patch pci-keystone-use-devm_request_irq-to-free-ks-pcie-error-irq-on-exit.patch pci-tegra194-fix-broken-tegra_pcie_ep_raise_msi_irq.patch rseq-selftests-use-weak-symbol-reference-not-definition-to-link-with-glibc.patch rtc-interface-ensure-alarm-irq-is-enabled-when-uie-is-enabled.patch rtc-interface-fix-long-standing-race-when-setting-alarm.patch scsi-hpsa-fix-potential-memory-leak-in-hpsa_big_passthru_ioctl.patch sctp-fix-mac-comparison-to-be-constant-time.patch sparc-fix-error-handling-in-scan_one_device.patch sparc64-fix-hugetlb-for-sun4u.patch spi-cadence-quadspi-flush-posted-register-writes-before-indac-access.patch x86-umip-check-that-the-instruction-opcode-is-at-least-two-bytes.patch x86-umip-fix-decoding-of-register-forms-of-0f-01-sgdt-and-sidt-aliases.patch --- diff --git a/queue-5.10/lib-genalloc-fix-device-leak-in-of_gen_pool_get.patch b/queue-5.10/lib-genalloc-fix-device-leak-in-of_gen_pool_get.patch new file mode 100644 index 0000000000..a687583ed8 --- /dev/null +++ b/queue-5.10/lib-genalloc-fix-device-leak-in-of_gen_pool_get.patch @@ -0,0 +1,43 @@ +From 1260cbcffa608219fc9188a6cbe9c45a300ef8b5 Mon Sep 17 00:00:00 2001 +From: Johan Hovold +Date: Wed, 24 Sep 2025 10:02:07 +0200 +Subject: lib/genalloc: fix device leak in of_gen_pool_get() + +From: Johan Hovold + +commit 1260cbcffa608219fc9188a6cbe9c45a300ef8b5 upstream. + +Make sure to drop the reference taken when looking up the genpool platform +device in of_gen_pool_get() before returning the pool. + +Note that holding a reference to a device does typically not prevent its +devres managed resources from being released so there is no point in +keeping the reference. + +Link: https://lkml.kernel.org/r/20250924080207.18006-1-johan@kernel.org +Fixes: 9375db07adea ("genalloc: add devres support, allow to find a managed pool by device") +Signed-off-by: Johan Hovold +Cc: Philipp Zabel +Cc: Vladimir Zapolskiy +Cc: [3.10+] +Signed-off-by: Andrew Morton +Signed-off-by: Greg Kroah-Hartman +--- + lib/genalloc.c | 5 ++++- + 1 file changed, 4 insertions(+), 1 deletion(-) + +--- a/lib/genalloc.c ++++ b/lib/genalloc.c +@@ -893,8 +893,11 @@ struct gen_pool *of_gen_pool_get(struct + if (!name) + name = np_pool->name; + } +- if (pdev) ++ if (pdev) { + pool = gen_pool_get(&pdev->dev, name); ++ put_device(&pdev->dev); ++ } ++ + of_node_put(np_pool); + + return pool; diff --git a/queue-5.10/memory-samsung-exynos-srom-fix-of_iomap-leak-in-exynos_srom_probe.patch b/queue-5.10/memory-samsung-exynos-srom-fix-of_iomap-leak-in-exynos_srom_probe.patch new file mode 100644 index 0000000000..e062ec5366 --- /dev/null +++ b/queue-5.10/memory-samsung-exynos-srom-fix-of_iomap-leak-in-exynos_srom_probe.patch @@ -0,0 +1,56 @@ +From 6744085079e785dae5f7a2239456135407c58b25 Mon Sep 17 00:00:00 2001 +From: Zhen Ni +Date: Wed, 6 Aug 2025 10:55:38 +0800 +Subject: memory: samsung: exynos-srom: Fix of_iomap leak in exynos_srom_probe + +From: Zhen Ni + +commit 6744085079e785dae5f7a2239456135407c58b25 upstream. + +The of_platform_populate() call at the end of the function has a +possible failure path, causing a resource leak. + +Replace of_iomap() with devm_platform_ioremap_resource() to ensure +automatic cleanup of srom->reg_base. + +This issue was detected by smatch static analysis: +drivers/memory/samsung/exynos-srom.c:155 exynos_srom_probe()warn: +'srom->reg_base' from of_iomap() not released on lines: 155. + +Fixes: 8ac2266d8831 ("memory: samsung: exynos-srom: Add support for bank configuration") +Cc: stable@vger.kernel.org +Signed-off-by: Zhen Ni +Link: https://lore.kernel.org/r/20250806025538.306593-1-zhen.ni@easystack.cn +Signed-off-by: Krzysztof Kozlowski +Signed-off-by: Greg Kroah-Hartman +--- + drivers/memory/samsung/exynos-srom.c | 10 ++++------ + 1 file changed, 4 insertions(+), 6 deletions(-) + +--- a/drivers/memory/samsung/exynos-srom.c ++++ b/drivers/memory/samsung/exynos-srom.c +@@ -121,20 +121,18 @@ static int exynos_srom_probe(struct plat + return -ENOMEM; + + srom->dev = dev; +- srom->reg_base = of_iomap(np, 0); +- if (!srom->reg_base) { ++ srom->reg_base = devm_platform_ioremap_resource(pdev, 0); ++ if (IS_ERR(srom->reg_base)) { + dev_err(&pdev->dev, "iomap of exynos srom controller failed\n"); +- return -ENOMEM; ++ return PTR_ERR(srom->reg_base); + } + + platform_set_drvdata(pdev, srom); + + srom->reg_offset = exynos_srom_alloc_reg_dump(exynos_srom_offsets, + ARRAY_SIZE(exynos_srom_offsets)); +- if (!srom->reg_offset) { +- iounmap(srom->reg_base); ++ if (!srom->reg_offset) + return -ENOMEM; +- } + + for_each_child_of_node(np, child) { + if (exynos_srom_configure_bank(srom, child)) { diff --git a/queue-5.10/mmc-core-spi-mode-remove-cmd7.patch b/queue-5.10/mmc-core-spi-mode-remove-cmd7.patch new file mode 100644 index 0000000000..f14e669f00 --- /dev/null +++ b/queue-5.10/mmc-core-spi-mode-remove-cmd7.patch @@ -0,0 +1,37 @@ +From fec40f44afdabcbc4a7748e4278f30737b54bb1a Mon Sep 17 00:00:00 2001 +From: Rex Chen +Date: Mon, 28 Jul 2025 17:22:29 +0900 +Subject: mmc: core: SPI mode remove cmd7 + +From: Rex Chen + +commit fec40f44afdabcbc4a7748e4278f30737b54bb1a upstream. + +SPI mode doesn't support cmd7, so remove it in mmc_sdio_alive() and +confirm if sdio is active by checking CCCR register value is available +or not. + +Signed-off-by: Rex Chen +Cc: stable@vger.kernel.org +Link: https://lore.kernel.org/r/20250728082230.1037917-2-rex.chen_1@nxp.com +Signed-off-by: Ulf Hansson +Signed-off-by: Greg Kroah-Hartman +--- + drivers/mmc/core/sdio.c | 6 +++++- + 1 file changed, 5 insertions(+), 1 deletion(-) + +--- a/drivers/mmc/core/sdio.c ++++ b/drivers/mmc/core/sdio.c +@@ -929,7 +929,11 @@ static void mmc_sdio_remove(struct mmc_h + */ + static int mmc_sdio_alive(struct mmc_host *host) + { +- return mmc_select_card(host->card); ++ if (!mmc_host_is_spi(host)) ++ return mmc_select_card(host->card); ++ else ++ return mmc_io_rw_direct(host->card, 0, 0, SDIO_CCCR_CCCR, 0, ++ NULL); + } + + /* diff --git a/queue-5.10/mtd-rawnand-fsmc-default-to-autodetect-buswidth.patch b/queue-5.10/mtd-rawnand-fsmc-default-to-autodetect-buswidth.patch new file mode 100644 index 0000000000..fc790c388d --- /dev/null +++ b/queue-5.10/mtd-rawnand-fsmc-default-to-autodetect-buswidth.patch @@ -0,0 +1,61 @@ +From b8df622cf7f6808c85764e681847150ed6d85f3d Mon Sep 17 00:00:00 2001 +From: Linus Walleij +Date: Tue, 16 Sep 2025 18:07:37 +0200 +Subject: mtd: rawnand: fsmc: Default to autodetect buswidth + +From: Linus Walleij + +commit b8df622cf7f6808c85764e681847150ed6d85f3d upstream. + +If you don't specify buswidth 2 (16 bits) in the device +tree, FSMC doesn't even probe anymore: + +fsmc-nand 10100000.flash: FSMC device partno 090, + manufacturer 80, revision 00, config 00 +nand: device found, Manufacturer ID: 0x20, Chip ID: 0xb1 +nand: ST Micro 10100000.flash +nand: bus width 8 instead of 16 bits +nand: No NAND device found +fsmc-nand 10100000.flash: probe with driver fsmc-nand failed + with error -22 + +With this patch to use autodetection unless buswidth is +specified, the device is properly detected again: + +fsmc-nand 10100000.flash: FSMC device partno 090, + manufacturer 80, revision 00, config 00 +nand: device found, Manufacturer ID: 0x20, Chip ID: 0xb1 +nand: ST Micro NAND 128MiB 1,8V 16-bit +nand: 128 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64 +fsmc-nand 10100000.flash: Using 1-bit HW ECC scheme +Scanning device for bad blocks + +I don't know where or how this happened, I think some change +in the nand core. + +Cc: stable@vger.kernel.org +Signed-off-by: Linus Walleij +Signed-off-by: Miquel Raynal +Signed-off-by: Greg Kroah-Hartman +--- + drivers/mtd/nand/raw/fsmc_nand.c | 6 +++++- + 1 file changed, 5 insertions(+), 1 deletion(-) + +--- a/drivers/mtd/nand/raw/fsmc_nand.c ++++ b/drivers/mtd/nand/raw/fsmc_nand.c +@@ -865,10 +865,14 @@ static int fsmc_nand_probe_config_dt(str + if (!of_property_read_u32(np, "bank-width", &val)) { + if (val == 2) { + nand->options |= NAND_BUSWIDTH_16; +- } else if (val != 1) { ++ } else if (val == 1) { ++ nand->options |= NAND_BUSWIDTH_AUTO; ++ } else { + dev_err(&pdev->dev, "invalid bank-width %u\n", val); + return -EINVAL; + } ++ } else { ++ nand->options |= NAND_BUSWIDTH_AUTO; + } + + if (of_get_property(np, "nand-skip-bbtscan", NULL)) diff --git a/queue-5.10/openat2-don-t-trigger-automounts-with-resolve_no_xdev.patch b/queue-5.10/openat2-don-t-trigger-automounts-with-resolve_no_xdev.patch new file mode 100644 index 0000000000..9dfba366f4 --- /dev/null +++ b/queue-5.10/openat2-don-t-trigger-automounts-with-resolve_no_xdev.patch @@ -0,0 +1,51 @@ +From 042a60680de43175eb4df0977ff04a4eba9da082 Mon Sep 17 00:00:00 2001 +From: Askar Safin +Date: Mon, 25 Aug 2025 18:12:33 +0000 +Subject: openat2: don't trigger automounts with RESOLVE_NO_XDEV + +From: Askar Safin + +commit 042a60680de43175eb4df0977ff04a4eba9da082 upstream. + +openat2 had a bug: if we pass RESOLVE_NO_XDEV, then openat2 +doesn't traverse through automounts, but may still trigger them. +(See the link for full bug report with reproducer.) + +This commit fixes this bug. + +Link: https://lore.kernel.org/linux-fsdevel/20250817075252.4137628-1-safinaskar@zohomail.com/ +Fixes: fddb5d430ad9fa91b49b1 ("open: introduce openat2(2) syscall") +Reviewed-by: Aleksa Sarai +Cc: stable@vger.kernel.org +Signed-off-by: Askar Safin +Link: https://lore.kernel.org/20250825181233.2464822-5-safinaskar@zohomail.com +Signed-off-by: Christian Brauner +Signed-off-by: Greg Kroah-Hartman +--- + fs/namei.c | 8 ++++++++ + 1 file changed, 8 insertions(+) + +--- a/fs/namei.c ++++ b/fs/namei.c +@@ -1202,6 +1202,10 @@ static int follow_automount(struct path + dentry->d_inode) + return -EISDIR; + ++ /* No need to trigger automounts if mountpoint crossing is disabled. */ ++ if (lookup_flags & LOOKUP_NO_XDEV) ++ return -EXDEV; ++ + if (count && (*count)++ >= MAXSYMLINKS) + return -ELOOP; + +@@ -1225,6 +1229,10 @@ static int __traverse_mounts(struct path + /* Allow the filesystem to manage the transit without i_mutex + * being held. */ + if (flags & DCACHE_MANAGE_TRANSIT) { ++ if (lookup_flags & LOOKUP_NO_XDEV) { ++ ret = -EXDEV; ++ break; ++ } + ret = path->dentry->d_op->d_manage(path, false); + flags = smp_load_acquire(&path->dentry->d_flags); + if (ret < 0) diff --git a/queue-5.10/parisc-don-t-reference-obsolete-termio-struct-for-tc-constants.patch b/queue-5.10/parisc-don-t-reference-obsolete-termio-struct-for-tc-constants.patch new file mode 100644 index 0000000000..284563cc73 --- /dev/null +++ b/queue-5.10/parisc-don-t-reference-obsolete-termio-struct-for-tc-constants.patch @@ -0,0 +1,44 @@ +From 8ec5a066f88f89bd52094ba18792b34c49dcd55a Mon Sep 17 00:00:00 2001 +From: Sam James +Date: Wed, 1 Oct 2025 23:58:40 +0100 +Subject: parisc: don't reference obsolete termio struct for TC* constants + +From: Sam James + +commit 8ec5a066f88f89bd52094ba18792b34c49dcd55a upstream. + +Similar in nature to ab107276607af90b13a5994997e19b7b9731e251. glibc-2.42 +drops the legacy termio struct, but the ioctls.h header still defines some +TC* constants in terms of termio (via sizeof). Hardcode the values instead. + +This fixes building Python for example, which falls over like: + ./Modules/termios.c:1119:16: error: invalid application of 'sizeof' to incomplete type 'struct termio' + +Link: https://bugs.gentoo.org/961769 +Link: https://bugs.gentoo.org/962600 +Co-authored-by: Stian Halseth +Cc: stable@vger.kernel.org +Signed-off-by: Sam James +Signed-off-by: Helge Deller +Signed-off-by: Greg Kroah-Hartman +--- + arch/parisc/include/uapi/asm/ioctls.h | 8 ++++---- + 1 file changed, 4 insertions(+), 4 deletions(-) + +--- a/arch/parisc/include/uapi/asm/ioctls.h ++++ b/arch/parisc/include/uapi/asm/ioctls.h +@@ -10,10 +10,10 @@ + #define TCSETS _IOW('T', 17, struct termios) /* TCSETATTR */ + #define TCSETSW _IOW('T', 18, struct termios) /* TCSETATTRD */ + #define TCSETSF _IOW('T', 19, struct termios) /* TCSETATTRF */ +-#define TCGETA _IOR('T', 1, struct termio) +-#define TCSETA _IOW('T', 2, struct termio) +-#define TCSETAW _IOW('T', 3, struct termio) +-#define TCSETAF _IOW('T', 4, struct termio) ++#define TCGETA 0x40125401 ++#define TCSETA 0x80125402 ++#define TCSETAW 0x80125403 ++#define TCSETAF 0x80125404 + #define TCSBRK _IO('T', 5) + #define TCXONC _IO('T', 6) + #define TCFLSH _IO('T', 7) diff --git a/queue-5.10/pci-aer-fix-missing-uevent-on-recovery-when-a-reset-is-requested.patch b/queue-5.10/pci-aer-fix-missing-uevent-on-recovery-when-a-reset-is-requested.patch new file mode 100644 index 0000000000..dec86e46ca --- /dev/null +++ b/queue-5.10/pci-aer-fix-missing-uevent-on-recovery-when-a-reset-is-requested.patch @@ -0,0 +1,37 @@ +From bbf7d0468d0da71d76cc6ec9bc8a224325d07b6b Mon Sep 17 00:00:00 2001 +From: Niklas Schnelle +Date: Thu, 7 Aug 2025 15:55:38 +0200 +Subject: PCI/AER: Fix missing uevent on recovery when a reset is requested + +From: Niklas Schnelle + +commit bbf7d0468d0da71d76cc6ec9bc8a224325d07b6b upstream. + +Since commit 7b42d97e99d3 ("PCI/ERR: Always report current recovery +status for udev") AER uses the result of error_detected() as parameter +to pci_uevent_ers(). As pci_uevent_ers() however does not handle +PCI_ERS_RESULT_NEED_RESET this results in a missing uevent for the +beginning of recovery if drivers request a reset. Fix this by treating +PCI_ERS_RESULT_NEED_RESET as beginning recovery. + +Fixes: 7b42d97e99d3 ("PCI/ERR: Always report current recovery status for udev") +Signed-off-by: Niklas Schnelle +Signed-off-by: Bjorn Helgaas +Reviewed-by: Lukas Wunner +Cc: stable@vger.kernel.org +Link: https://patch.msgid.link/20250807-add_err_uevents-v5-1-adf85b0620b0@linux.ibm.com +Signed-off-by: Greg Kroah-Hartman +--- + drivers/pci/pci-driver.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/drivers/pci/pci-driver.c ++++ b/drivers/pci/pci-driver.c +@@ -1546,6 +1546,7 @@ void pci_uevent_ers(struct pci_dev *pdev + switch (err_type) { + case PCI_ERS_RESULT_NONE: + case PCI_ERS_RESULT_CAN_RECOVER: ++ case PCI_ERS_RESULT_NEED_RESET: + envp[idx++] = "ERROR_EVENT=BEGIN_RECOVERY"; + envp[idx++] = "DEVICE_ONLINE=0"; + break; diff --git a/queue-5.10/pci-aer-support-errors-introduced-by-pcie-r6.0.patch b/queue-5.10/pci-aer-support-errors-introduced-by-pcie-r6.0.patch new file mode 100644 index 0000000000..5d8cc41bc1 --- /dev/null +++ b/queue-5.10/pci-aer-support-errors-introduced-by-pcie-r6.0.patch @@ -0,0 +1,58 @@ +From 6633875250b38b18b8638cf01e695de031c71f02 Mon Sep 17 00:00:00 2001 +From: Lukas Wunner +Date: Wed, 27 Aug 2025 15:41:09 +0200 +Subject: PCI/AER: Support errors introduced by PCIe r6.0 + +From: Lukas Wunner + +commit 6633875250b38b18b8638cf01e695de031c71f02 upstream. + +PCIe r6.0 defined five additional errors in the Uncorrectable Error +Status, Mask and Severity Registers (PCIe r7.0 sec 7.8.4.2ff). + +lspci has been supporting them since commit 144b0911cc0b ("ls-ecaps: +extend decode support for more fields for AER CE and UE status"): + + https://git.kernel.org/pub/scm/utils/pciutils/pciutils.git/commit/?id=144b0911cc0b + +Amend the AER driver to recognize them as well, instead of logging them as +"Unknown Error Bit". + +Signed-off-by: Lukas Wunner +Signed-off-by: Bjorn Helgaas +Reviewed-by: Kuppuswamy Sathyanarayanan +Cc: stable@vger.kernel.org +Link: https://patch.msgid.link/21f1875b18d4078c99353378f37dcd6b994f6d4e.1756301211.git.lukas@wunner.de +Signed-off-by: Greg Kroah-Hartman +--- + drivers/pci/pcie/aer.c | 12 ++++++------ + 1 file changed, 6 insertions(+), 6 deletions(-) + +--- a/drivers/pci/pcie/aer.c ++++ b/drivers/pci/pcie/aer.c +@@ -37,7 +37,7 @@ + #define AER_ERROR_SOURCES_MAX 128 + + #define AER_MAX_TYPEOF_COR_ERRS 16 /* as per PCI_ERR_COR_STATUS */ +-#define AER_MAX_TYPEOF_UNCOR_ERRS 27 /* as per PCI_ERR_UNCOR_STATUS*/ ++#define AER_MAX_TYPEOF_UNCOR_ERRS 32 /* as per PCI_ERR_UNCOR_STATUS*/ + + struct aer_err_source { + unsigned int status; +@@ -513,11 +513,11 @@ static const char *aer_uncorrectable_err + "AtomicOpBlocked", /* Bit Position 24 */ + "TLPBlockedErr", /* Bit Position 25 */ + "PoisonTLPBlocked", /* Bit Position 26 */ +- NULL, /* Bit Position 27 */ +- NULL, /* Bit Position 28 */ +- NULL, /* Bit Position 29 */ +- NULL, /* Bit Position 30 */ +- NULL, /* Bit Position 31 */ ++ "DMWrReqBlocked", /* Bit Position 27 */ ++ "IDECheck", /* Bit Position 28 */ ++ "MisIDETLP", /* Bit Position 29 */ ++ "PCRC_CHECK", /* Bit Position 30 */ ++ "TLPXlatBlocked", /* Bit Position 31 */ + }; + + static const char *aer_agent_string[] = { diff --git a/queue-5.10/pci-err-fix-uevent-on-failure-to-recover.patch b/queue-5.10/pci-err-fix-uevent-on-failure-to-recover.patch new file mode 100644 index 0000000000..810ec34073 --- /dev/null +++ b/queue-5.10/pci-err-fix-uevent-on-failure-to-recover.patch @@ -0,0 +1,59 @@ +From 1cbc5e25fb70e942a7a735a1f3d6dd391afc9b29 Mon Sep 17 00:00:00 2001 +From: Lukas Wunner +Date: Wed, 13 Aug 2025 07:11:02 +0200 +Subject: PCI/ERR: Fix uevent on failure to recover + +From: Lukas Wunner + +commit 1cbc5e25fb70e942a7a735a1f3d6dd391afc9b29 upstream. + +Upon failure to recover from a PCIe error through AER, DPC or EDR, a +uevent is sent to inform user space about disconnection of the bridge +whose subordinate devices failed to recover. + +However the bridge itself is not disconnected. Instead, a uevent should +be sent for each of the subordinate devices. + +Only if the "bridge" happens to be a Root Complex Event Collector or +Integrated Endpoint does it make sense to send a uevent for it (because +there are no subordinate devices). + +Right now if there is a mix of subordinate devices with and without +pci_error_handlers, a BEGIN_RECOVERY event is sent for those with +pci_error_handlers but no FAILED_RECOVERY event is ever sent for them +afterwards. Fix it. + +Fixes: 856e1eb9bdd4 ("PCI/AER: Add uevents in AER and EEH error/resume") +Signed-off-by: Lukas Wunner +Signed-off-by: Bjorn Helgaas +Cc: stable@vger.kernel.org # v4.16+ +Link: https://patch.msgid.link/68fc527a380821b5d861dd554d2ce42cb739591c.1755008151.git.lukas@wunner.de +Signed-off-by: Greg Kroah-Hartman +--- + drivers/pci/pcie/err.c | 8 +++++++- + 1 file changed, 7 insertions(+), 1 deletion(-) + +--- a/drivers/pci/pcie/err.c ++++ b/drivers/pci/pcie/err.c +@@ -102,6 +102,12 @@ static int report_normal_detected(struct + return report_error_detected(dev, pci_channel_io_normal, data); + } + ++static int report_perm_failure_detected(struct pci_dev *dev, void *data) ++{ ++ pci_uevent_ers(dev, PCI_ERS_RESULT_DISCONNECT); ++ return 0; ++} ++ + static int report_mmio_enabled(struct pci_dev *dev, void *data) + { + pci_ers_result_t vote, *result = data; +@@ -263,7 +269,7 @@ pci_ers_result_t pcie_do_recovery(struct + failed: + pci_walk_bridge(bridge, pci_pm_runtime_put, NULL); + +- pci_uevent_ers(bridge, PCI_ERS_RESULT_DISCONNECT); ++ pci_walk_bridge(bridge, report_perm_failure_detected, NULL); + + /* TODO: Should kernel panic here? */ + pci_info(bridge, "device recovery failed\n"); diff --git a/queue-5.10/pci-iov-add-pci-rescan-remove-locking-when-enabling-disabling-sr-iov.patch b/queue-5.10/pci-iov-add-pci-rescan-remove-locking-when-enabling-disabling-sr-iov.patch new file mode 100644 index 0000000000..e9e9f22d0d --- /dev/null +++ b/queue-5.10/pci-iov-add-pci-rescan-remove-locking-when-enabling-disabling-sr-iov.patch @@ -0,0 +1,105 @@ +From 05703271c3cdcc0f2a8cf6ebdc45892b8ca83520 Mon Sep 17 00:00:00 2001 +From: Niklas Schnelle +Date: Tue, 26 Aug 2025 10:52:08 +0200 +Subject: PCI/IOV: Add PCI rescan-remove locking when enabling/disabling SR-IOV + +From: Niklas Schnelle + +commit 05703271c3cdcc0f2a8cf6ebdc45892b8ca83520 upstream. + +Before disabling SR-IOV via config space accesses to the parent PF, +sriov_disable() first removes the PCI devices representing the VFs. + +Since commit 9d16947b7583 ("PCI: Add global pci_lock_rescan_remove()") +such removal operations are serialized against concurrent remove and +rescan using the pci_rescan_remove_lock. No such locking was ever added +in sriov_disable() however. In particular when commit 18f9e9d150fc +("PCI/IOV: Factor out sriov_add_vfs()") factored out the PCI device +removal into sriov_del_vfs() there was still no locking around the +pci_iov_remove_virtfn() calls. + +On s390 the lack of serialization in sriov_disable() may cause double +remove and list corruption with the below (amended) trace being observed: + + PSW: 0704c00180000000 0000000c914e4b38 (klist_put+56) + GPRS: 000003800313fb48 0000000000000000 0000000100000001 0000000000000001 + 00000000f9b520a8 0000000000000000 0000000000002fbd 00000000f4cc9480 + 0000000000000001 0000000000000000 0000000000000000 0000000180692828 + 00000000818e8000 000003800313fe2c 000003800313fb20 000003800313fad8 + #0 [3800313fb20] device_del at c9158ad5c + #1 [3800313fb88] pci_remove_bus_device at c915105ba + #2 [3800313fbd0] pci_iov_remove_virtfn at c9152f198 + #3 [3800313fc28] zpci_iov_remove_virtfn at c90fb67c0 + #4 [3800313fc60] zpci_bus_remove_device at c90fb6104 + #5 [3800313fca0] __zpci_event_availability at c90fb3dca + #6 [3800313fd08] chsc_process_sei_nt0 at c918fe4a2 + #7 [3800313fd60] crw_collect_info at c91905822 + #8 [3800313fe10] kthread at c90feb390 + #9 [3800313fe68] __ret_from_fork at c90f6aa64 + #10 [3800313fe98] ret_from_fork at c9194f3f2. + +This is because in addition to sriov_disable() removing the VFs, the +platform also generates hot-unplug events for the VFs. This being the +reverse operation to the hotplug events generated by sriov_enable() and +handled via pdev->no_vf_scan. And while the event processing takes +pci_rescan_remove_lock and checks whether the struct pci_dev still exists, +the lack of synchronization makes this checking racy. + +Other races may also be possible of course though given that this lack of +locking persisted so long observable races seem very rare. Even on s390 the +list corruption was only observed with certain devices since the platform +events are only triggered by config accesses after the removal, so as long +as the removal finished synchronously they would not race. Either way the +locking is missing so fix this by adding it to the sriov_del_vfs() helper. + +Just like PCI rescan-remove, locking is also missing in sriov_add_vfs() +including for the error case where pci_stop_and_remove_bus_device() is +called without the PCI rescan-remove lock being held. Even in the non-error +case, adding new PCI devices and buses should be serialized via the PCI +rescan-remove lock. Add the necessary locking. + +Fixes: 18f9e9d150fc ("PCI/IOV: Factor out sriov_add_vfs()") +Signed-off-by: Niklas Schnelle +Signed-off-by: Bjorn Helgaas +Reviewed-by: Benjamin Block +Reviewed-by: Farhan Ali +Reviewed-by: Julian Ruess +Cc: stable@vger.kernel.org +Link: https://patch.msgid.link/20250826-pci_fix_sriov_disable-v1-1-2d0bc938f2a3@linux.ibm.com +Signed-off-by: Greg Kroah-Hartman +--- + drivers/pci/iov.c | 5 +++++ + 1 file changed, 5 insertions(+) + +--- a/drivers/pci/iov.c ++++ b/drivers/pci/iov.c +@@ -444,15 +444,18 @@ static int sriov_add_vfs(struct pci_dev + if (dev->no_vf_scan) + return 0; + ++ pci_lock_rescan_remove(); + for (i = 0; i < num_vfs; i++) { + rc = pci_iov_add_virtfn(dev, i); + if (rc) + goto failed; + } ++ pci_unlock_rescan_remove(); + return 0; + failed: + while (i--) + pci_iov_remove_virtfn(dev, i); ++ pci_unlock_rescan_remove(); + + return rc; + } +@@ -572,8 +575,10 @@ static void sriov_del_vfs(struct pci_dev + struct pci_sriov *iov = dev->sriov; + int i; + ++ pci_lock_rescan_remove(); + for (i = 0; i < iov->num_VFs; i++) + pci_iov_remove_virtfn(dev, i); ++ pci_unlock_rescan_remove(); + } + + static void sriov_disable(struct pci_dev *dev) diff --git a/queue-5.10/pci-keystone-use-devm_request_irq-to-free-ks-pcie-error-irq-on-exit.patch b/queue-5.10/pci-keystone-use-devm_request_irq-to-free-ks-pcie-error-irq-on-exit.patch new file mode 100644 index 0000000000..a30a6bfe74 --- /dev/null +++ b/queue-5.10/pci-keystone-use-devm_request_irq-to-free-ks-pcie-error-irq-on-exit.patch @@ -0,0 +1,43 @@ +From e51d05f523e43ce5d2bad957943a2b14f68078cd Mon Sep 17 00:00:00 2001 +From: Siddharth Vadapalli +Date: Fri, 12 Sep 2025 15:37:58 +0530 +Subject: PCI: keystone: Use devm_request_irq() to free "ks-pcie-error-irq" on exit + +From: Siddharth Vadapalli + +commit e51d05f523e43ce5d2bad957943a2b14f68078cd upstream. + +Commit under Fixes introduced the IRQ handler for "ks-pcie-error-irq". +The interrupt is acquired using "request_irq()" but is never freed if +the driver exits due to an error. Although the section in the driver that +invokes "request_irq()" has moved around over time, the issue hasn't been +addressed until now. + +Fix this by using "devm_request_irq()" which automatically frees the +interrupt if the driver exits. + +Fixes: 025dd3daeda7 ("PCI: keystone: Add error IRQ handler") +Reported-by: Jiri Slaby +Closes: https://lore.kernel.org/r/3d3a4b52-e343-42f3-9d69-94c259812143@kernel.org +Signed-off-by: Siddharth Vadapalli +Signed-off-by: Manivannan Sadhasivam +Cc: stable@vger.kernel.org +Link: https://patch.msgid.link/20250912100802.3136121-2-s-vadapalli@ti.com +Signed-off-by: Greg Kroah-Hartman +--- + drivers/pci/controller/dwc/pci-keystone.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +--- a/drivers/pci/controller/dwc/pci-keystone.c ++++ b/drivers/pci/controller/dwc/pci-keystone.c +@@ -1261,8 +1261,8 @@ static int ks_pcie_probe(struct platform + if (irq < 0) + return irq; + +- ret = request_irq(irq, ks_pcie_err_irq_handler, IRQF_SHARED, +- "ks-pcie-error-irq", ks_pcie); ++ ret = devm_request_irq(dev, irq, ks_pcie_err_irq_handler, IRQF_SHARED, ++ "ks-pcie-error-irq", ks_pcie); + if (ret < 0) { + dev_err(dev, "failed to request error IRQ %d\n", + irq); diff --git a/queue-5.10/pci-tegra194-fix-broken-tegra_pcie_ep_raise_msi_irq.patch b/queue-5.10/pci-tegra194-fix-broken-tegra_pcie_ep_raise_msi_irq.patch new file mode 100644 index 0000000000..5b6d9ff7dd --- /dev/null +++ b/queue-5.10/pci-tegra194-fix-broken-tegra_pcie_ep_raise_msi_irq.patch @@ -0,0 +1,43 @@ +From b640d42a6ac9ba01abe65ec34f7c73aaf6758ab8 Mon Sep 17 00:00:00 2001 +From: Niklas Cassel +Date: Mon, 22 Sep 2025 16:08:24 +0200 +Subject: PCI: tegra194: Fix broken tegra_pcie_ep_raise_msi_irq() + +From: Niklas Cassel + +commit b640d42a6ac9ba01abe65ec34f7c73aaf6758ab8 upstream. + +The pci_epc_raise_irq() supplies a MSI or MSI-X interrupt number in range +(1-N), as per the pci_epc_raise_irq() kdoc, where N is 32 for MSI. + +But tegra_pcie_ep_raise_msi_irq() incorrectly uses the interrupt number as +the MSI vector. This causes wrong MSI vector to be triggered, leading to +the failure of PCI endpoint Kselftest MSI_TEST test case. + +To fix this issue, convert the interrupt number to MSI vector. + +Fixes: c57247f940e8 ("PCI: tegra: Add support for PCIe endpoint mode in Tegra194") +Signed-off-by: Niklas Cassel +Signed-off-by: Manivannan Sadhasivam +Cc: stable@vger.kernel.org +Link: https://patch.msgid.link/20250922140822.519796-6-cassel@kernel.org +Signed-off-by: Greg Kroah-Hartman +--- + drivers/pci/controller/dwc/pcie-tegra194.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +--- a/drivers/pci/controller/dwc/pcie-tegra194.c ++++ b/drivers/pci/controller/dwc/pcie-tegra194.c +@@ -1844,10 +1844,10 @@ static int tegra_pcie_ep_raise_legacy_ir + + static int tegra_pcie_ep_raise_msi_irq(struct tegra_pcie_dw *pcie, u16 irq) + { +- if (unlikely(irq > 31)) ++ if (unlikely(irq > 32)) + return -EINVAL; + +- appl_writel(pcie, BIT(irq), APPL_MSI_CTRL_1); ++ appl_writel(pcie, BIT(irq - 1), APPL_MSI_CTRL_1); + + return 0; + } diff --git a/queue-5.10/rseq-selftests-use-weak-symbol-reference-not-definition-to-link-with-glibc.patch b/queue-5.10/rseq-selftests-use-weak-symbol-reference-not-definition-to-link-with-glibc.patch new file mode 100644 index 0000000000..d9cdc71513 --- /dev/null +++ b/queue-5.10/rseq-selftests-use-weak-symbol-reference-not-definition-to-link-with-glibc.patch @@ -0,0 +1,63 @@ +From a001cd248ab244633c5fabe4f7c707e13fc1d1cc Mon Sep 17 00:00:00 2001 +From: Sean Christopherson +Date: Tue, 19 Aug 2025 15:29:44 -0700 +Subject: rseq/selftests: Use weak symbol reference, not definition, to link with glibc + +From: Sean Christopherson + +commit a001cd248ab244633c5fabe4f7c707e13fc1d1cc upstream. + +Add "extern" to the glibc-defined weak rseq symbols to convert the rseq +selftest's usage from weak symbol definitions to weak symbol _references_. +Effectively re-defining the glibc symbols wreaks havoc when building with +-fno-common, e.g. generates segfaults when running multi-threaded programs, +as dynamically linked applications end up with multiple versions of the +symbols. + +Building with -fcommon, which until recently has the been the default for +GCC and clang, papers over the bug by allowing the linker to resolve the +weak/tentative definition to glibc's "real" definition. + +Note, the symbol itself (or rather its address), not the value of the +symbol, is set to 0/NULL for unresolved weak symbol references, as the +symbol doesn't exist and thus can't have a value. Check for a NULL rseq +size pointer to handle the scenario where the test is statically linked +against a libc that doesn't support rseq in any capacity. + +Fixes: 3bcbc20942db ("selftests/rseq: Play nice with binaries statically linked against glibc 2.35+") +Reported-by: Thomas Gleixner +Suggested-by: Florian Weimer +Signed-off-by: Sean Christopherson +Signed-off-by: Thomas Gleixner +Reviewed-by: Mathieu Desnoyers +Cc: stable@vger.kernel.org +Closes: https://lore.kernel.org/all/87frdoybk4.ffs@tglx +Signed-off-by: Greg Kroah-Hartman +--- + tools/testing/selftests/rseq/rseq.c | 8 ++++---- + 1 file changed, 4 insertions(+), 4 deletions(-) + +--- a/tools/testing/selftests/rseq/rseq.c ++++ b/tools/testing/selftests/rseq/rseq.c +@@ -38,9 +38,9 @@ + * Define weak versions to play nice with binaries that are statically linked + * against a libc that doesn't support registering its own rseq. + */ +-__weak ptrdiff_t __rseq_offset; +-__weak unsigned int __rseq_size; +-__weak unsigned int __rseq_flags; ++extern __weak ptrdiff_t __rseq_offset; ++extern __weak unsigned int __rseq_size; ++extern __weak unsigned int __rseq_flags; + + static const ptrdiff_t *libc_rseq_offset_p = &__rseq_offset; + static const unsigned int *libc_rseq_size_p = &__rseq_size; +@@ -124,7 +124,7 @@ void rseq_init(void) + * libc not having registered a restartable sequence. Try to find the + * symbols if that's the case. + */ +- if (!*libc_rseq_size_p) { ++ if (!libc_rseq_size_p || !*libc_rseq_size_p) { + libc_rseq_offset_p = dlsym(RTLD_NEXT, "__rseq_offset"); + libc_rseq_size_p = dlsym(RTLD_NEXT, "__rseq_size"); + libc_rseq_flags_p = dlsym(RTLD_NEXT, "__rseq_flags"); diff --git a/queue-5.10/rtc-interface-ensure-alarm-irq-is-enabled-when-uie-is-enabled.patch b/queue-5.10/rtc-interface-ensure-alarm-irq-is-enabled-when-uie-is-enabled.patch new file mode 100644 index 0000000000..5eb267deb1 --- /dev/null +++ b/queue-5.10/rtc-interface-ensure-alarm-irq-is-enabled-when-uie-is-enabled.patch @@ -0,0 +1,39 @@ +From 9db26d5855d0374d4652487bfb5aacf40821c469 Mon Sep 17 00:00:00 2001 +From: Esben Haabendal +Date: Fri, 16 May 2025 09:23:39 +0200 +Subject: rtc: interface: Ensure alarm irq is enabled when UIE is enabled + +From: Esben Haabendal + +commit 9db26d5855d0374d4652487bfb5aacf40821c469 upstream. + +When setting a normal alarm, user-space is responsible for using +RTC_AIE_ON/RTC_AIE_OFF to control if alarm irq should be enabled. + +But when RTC_UIE_ON is used, interrupts must be enabled so that the +requested irq events are generated. +When RTC_UIE_OFF is used, alarm irq is disabled if there are no other +alarms queued, so this commit brings symmetry to that. + +Signed-off-by: Esben Haabendal +Cc: stable@vger.kernel.org +Link: https://lore.kernel.org/r/20250516-rtc-uie-irq-fixes-v2-5-3de8e530a39e@geanix.com +Signed-off-by: Alexandre Belloni +Signed-off-by: Greg Kroah-Hartman +--- + drivers/rtc/interface.c | 4 ++++ + 1 file changed, 4 insertions(+) + +--- a/drivers/rtc/interface.c ++++ b/drivers/rtc/interface.c +@@ -579,6 +579,10 @@ int rtc_update_irq_enable(struct rtc_dev + rtc->uie_rtctimer.node.expires = ktime_add(now, onesec); + rtc->uie_rtctimer.period = ktime_set(1, 0); + err = rtc_timer_enqueue(rtc, &rtc->uie_rtctimer); ++ if (!err && rtc->ops && rtc->ops->alarm_irq_enable) ++ err = rtc->ops->alarm_irq_enable(rtc->dev.parent, 1); ++ if (err) ++ goto out; + } else { + rtc_timer_remove(rtc, &rtc->uie_rtctimer); + } diff --git a/queue-5.10/rtc-interface-fix-long-standing-race-when-setting-alarm.patch b/queue-5.10/rtc-interface-fix-long-standing-race-when-setting-alarm.patch new file mode 100644 index 0000000000..0c2b8bff9c --- /dev/null +++ b/queue-5.10/rtc-interface-fix-long-standing-race-when-setting-alarm.patch @@ -0,0 +1,71 @@ +From 795cda8338eab036013314dbc0b04aae728880ab Mon Sep 17 00:00:00 2001 +From: Esben Haabendal +Date: Fri, 16 May 2025 09:23:35 +0200 +Subject: rtc: interface: Fix long-standing race when setting alarm + +From: Esben Haabendal + +commit 795cda8338eab036013314dbc0b04aae728880ab upstream. + +As described in the old comment dating back to +commit 6610e0893b8b ("RTC: Rework RTC code to use timerqueue for events") +from 2010, we have been living with a race window when setting alarm +with an expiry in the near future (i.e. next second). +With 1 second resolution, it can happen that the second ticks after the +check for the timer having expired, but before the alarm is actually set. +When this happen, no alarm IRQ is generated, at least not with some RTC +chips (isl12022 is an example of this). + +With UIE RTC timer being implemented on top of alarm irq, being re-armed +every second, UIE will occasionally fail to work, as an alarm irq lost +due to this race will stop the re-arming loop. + +For now, I have limited the additional expiry check to only be done for +alarms set to next seconds. I expect it should be good enough, although I +don't know if we can now for sure that systems with loads could end up +causing the same problems for alarms set 2 seconds or even longer in the +future. + +I haven't been able to reproduce the problem with this check in place. + +Cc: stable@vger.kernel.org +Signed-off-by: Esben Haabendal +Link: https://lore.kernel.org/r/20250516-rtc-uie-irq-fixes-v2-1-3de8e530a39e@geanix.com +Signed-off-by: Alexandre Belloni +Signed-off-by: Greg Kroah-Hartman +--- + drivers/rtc/interface.c | 23 +++++++++++++++++++++++ + 1 file changed, 23 insertions(+) + +--- a/drivers/rtc/interface.c ++++ b/drivers/rtc/interface.c +@@ -442,6 +442,29 @@ static int __rtc_set_alarm(struct rtc_de + else + err = rtc->ops->set_alarm(rtc->dev.parent, alarm); + ++ /* ++ * Check for potential race described above. If the waiting for next ++ * second, and the second just ticked since the check above, either ++ * ++ * 1) It ticked after the alarm was set, and an alarm irq should be ++ * generated. ++ * ++ * 2) It ticked before the alarm was set, and alarm irq most likely will ++ * not be generated. ++ * ++ * While we cannot easily check for which of these two scenarios we ++ * are in, we can return -ETIME to signal that the timer has already ++ * expired, which is true in both cases. ++ */ ++ if ((scheduled - now) <= 1) { ++ err = __rtc_read_time(rtc, &tm); ++ if (err) ++ return err; ++ now = rtc_tm_to_time64(&tm); ++ if (scheduled <= now) ++ return -ETIME; ++ } ++ + trace_rtc_set_alarm(rtc_tm_to_time64(&alarm->time), err); + return err; + } diff --git a/queue-5.10/scsi-hpsa-fix-potential-memory-leak-in-hpsa_big_passthru_ioctl.patch b/queue-5.10/scsi-hpsa-fix-potential-memory-leak-in-hpsa_big_passthru_ioctl.patch new file mode 100644 index 0000000000..e09a506bcf --- /dev/null +++ b/queue-5.10/scsi-hpsa-fix-potential-memory-leak-in-hpsa_big_passthru_ioctl.patch @@ -0,0 +1,60 @@ +From b81296591c567b12d3873b05a37b975707959b94 Mon Sep 17 00:00:00 2001 +From: Thorsten Blum +Date: Fri, 19 Sep 2025 11:26:37 +0200 +Subject: scsi: hpsa: Fix potential memory leak in hpsa_big_passthru_ioctl() + +From: Thorsten Blum + +commit b81296591c567b12d3873b05a37b975707959b94 upstream. + +Replace kmalloc() followed by copy_from_user() with memdup_user() to fix +a memory leak that occurs when copy_from_user(buff[sg_used],,) fails and +the 'cleanup1:' path does not free the memory for 'buff[sg_used]'. Using +memdup_user() avoids this by freeing the memory internally. + +Since memdup_user() already allocates memory, use kzalloc() in the else +branch instead of manually zeroing 'buff[sg_used]' using memset(0). + +Cc: stable@vger.kernel.org +Fixes: edd163687ea5 ("[SCSI] hpsa: add driver for HP Smart Array controllers.") +Signed-off-by: Thorsten Blum +Acked-by: Don Brace +Signed-off-by: Martin K. Petersen +Signed-off-by: Greg Kroah-Hartman +--- + drivers/scsi/hpsa.c | 21 ++++++++++++--------- + 1 file changed, 12 insertions(+), 9 deletions(-) + +--- a/drivers/scsi/hpsa.c ++++ b/drivers/scsi/hpsa.c +@@ -6500,18 +6500,21 @@ static int hpsa_big_passthru_ioctl(struc + while (left) { + sz = (left > ioc->malloc_size) ? ioc->malloc_size : left; + buff_size[sg_used] = sz; +- buff[sg_used] = kmalloc(sz, GFP_KERNEL); +- if (buff[sg_used] == NULL) { +- status = -ENOMEM; +- goto cleanup1; +- } ++ + if (ioc->Request.Type.Direction & XFER_WRITE) { +- if (copy_from_user(buff[sg_used], data_ptr, sz)) { +- status = -EFAULT; ++ buff[sg_used] = memdup_user(data_ptr, sz); ++ if (IS_ERR(buff[sg_used])) { ++ status = PTR_ERR(buff[sg_used]); ++ goto cleanup1; ++ } ++ } else { ++ buff[sg_used] = kzalloc(sz, GFP_KERNEL); ++ if (!buff[sg_used]) { ++ status = -ENOMEM; + goto cleanup1; + } +- } else +- memset(buff[sg_used], 0, sz); ++ } ++ + left -= sz; + data_ptr += sz; + sg_used++; diff --git a/queue-5.10/sctp-fix-mac-comparison-to-be-constant-time.patch b/queue-5.10/sctp-fix-mac-comparison-to-be-constant-time.patch new file mode 100644 index 0000000000..99a3fbdb6b --- /dev/null +++ b/queue-5.10/sctp-fix-mac-comparison-to-be-constant-time.patch @@ -0,0 +1,62 @@ +From dd91c79e4f58fbe2898dac84858033700e0e99fb Mon Sep 17 00:00:00 2001 +From: Eric Biggers +Date: Mon, 18 Aug 2025 13:54:23 -0700 +Subject: sctp: Fix MAC comparison to be constant-time + +From: Eric Biggers + +commit dd91c79e4f58fbe2898dac84858033700e0e99fb upstream. + +To prevent timing attacks, MACs need to be compared in constant time. +Use the appropriate helper function for this. + +Fixes: bbd0d59809f9 ("[SCTP]: Implement the receive and verification of AUTH chunk") +Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") +Cc: stable@vger.kernel.org +Signed-off-by: Eric Biggers +Link: https://patch.msgid.link/20250818205426.30222-3-ebiggers@kernel.org +Signed-off-by: Jakub Kicinski +Signed-off-by: Greg Kroah-Hartman +--- + net/sctp/sm_make_chunk.c | 3 ++- + net/sctp/sm_statefuns.c | 3 ++- + 2 files changed, 4 insertions(+), 2 deletions(-) + +--- a/net/sctp/sm_make_chunk.c ++++ b/net/sctp/sm_make_chunk.c +@@ -31,6 +31,7 @@ + #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt + + #include ++#include + #include + #include + #include +@@ -1751,7 +1752,7 @@ struct sctp_association *sctp_unpack_coo + } + } + +- if (memcmp(digest, cookie->signature, SCTP_SIGNATURE_SIZE)) { ++ if (crypto_memneq(digest, cookie->signature, SCTP_SIGNATURE_SIZE)) { + *error = -SCTP_IERROR_BAD_SIG; + goto fail; + } +--- a/net/sctp/sm_statefuns.c ++++ b/net/sctp/sm_statefuns.c +@@ -30,6 +30,7 @@ + + #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt + ++#include + #include + #include + #include +@@ -4303,7 +4304,7 @@ static enum sctp_ierror sctp_sf_authenti + sh_key, GFP_ATOMIC); + + /* Discard the packet if the digests do not match */ +- if (memcmp(save_digest, digest, sig_len)) { ++ if (crypto_memneq(save_digest, digest, sig_len)) { + kfree(save_digest); + return SCTP_IERROR_BAD_SIG; + } diff --git a/queue-5.10/series b/queue-5.10/series index 320392cd16..63079b5be5 100644 --- a/queue-5.10/series +++ b/queue-5.10/series @@ -142,3 +142,25 @@ iio-dac-ad5421-use-int-type-to-store-negative-error-codes.patch iio-frequency-adf4350-fix-prescaler-usage.patch init-handle-bootloader-identifier-in-kernel-parameters.patch iio-imu-inv_icm42600-drop-redundant-pm_runtime-reinitialization-in-resume.patch +lib-genalloc-fix-device-leak-in-of_gen_pool_get.patch +openat2-don-t-trigger-automounts-with-resolve_no_xdev.patch +parisc-don-t-reference-obsolete-termio-struct-for-tc-constants.patch +scsi-hpsa-fix-potential-memory-leak-in-hpsa_big_passthru_ioctl.patch +sctp-fix-mac-comparison-to-be-constant-time.patch +sparc64-fix-hugetlb-for-sun4u.patch +sparc-fix-error-handling-in-scan_one_device.patch +mtd-rawnand-fsmc-default-to-autodetect-buswidth.patch +mmc-core-spi-mode-remove-cmd7.patch +memory-samsung-exynos-srom-fix-of_iomap-leak-in-exynos_srom_probe.patch +rtc-interface-ensure-alarm-irq-is-enabled-when-uie-is-enabled.patch +rtc-interface-fix-long-standing-race-when-setting-alarm.patch +rseq-selftests-use-weak-symbol-reference-not-definition-to-link-with-glibc.patch +pci-iov-add-pci-rescan-remove-locking-when-enabling-disabling-sr-iov.patch +pci-err-fix-uevent-on-failure-to-recover.patch +pci-aer-fix-missing-uevent-on-recovery-when-a-reset-is-requested.patch +pci-aer-support-errors-introduced-by-pcie-r6.0.patch +pci-keystone-use-devm_request_irq-to-free-ks-pcie-error-irq-on-exit.patch +pci-tegra194-fix-broken-tegra_pcie_ep_raise_msi_irq.patch +spi-cadence-quadspi-flush-posted-register-writes-before-indac-access.patch +x86-umip-check-that-the-instruction-opcode-is-at-least-two-bytes.patch +x86-umip-fix-decoding-of-register-forms-of-0f-01-sgdt-and-sidt-aliases.patch diff --git a/queue-5.10/sparc-fix-error-handling-in-scan_one_device.patch b/queue-5.10/sparc-fix-error-handling-in-scan_one_device.patch new file mode 100644 index 0000000000..3530e047f2 --- /dev/null +++ b/queue-5.10/sparc-fix-error-handling-in-scan_one_device.patch @@ -0,0 +1,52 @@ +From 302c04110f0ce70d25add2496b521132548cd408 Mon Sep 17 00:00:00 2001 +From: Ma Ke +Date: Sat, 20 Sep 2025 20:53:12 +0800 +Subject: sparc: fix error handling in scan_one_device() + +From: Ma Ke + +commit 302c04110f0ce70d25add2496b521132548cd408 upstream. + +Once of_device_register() failed, we should call put_device() to +decrement reference count for cleanup. Or it could cause memory leak. +So fix this by calling put_device(), then the name can be freed in +kobject_cleanup(). + +Calling path: of_device_register() -> of_device_add() -> device_add(). +As comment of device_add() says, 'if device_add() succeeds, you should +call device_del() when you want to get rid of it. If device_add() has +not succeeded, use only put_device() to drop the reference count'. + +Found by code review. + +Cc: stable@vger.kernel.org +Fixes: cf44bbc26cf1 ("[SPARC]: Beginnings of generic of_device framework.") +Signed-off-by: Ma Ke +Reviewed-by: Andreas Larsson +Signed-off-by: Andreas Larsson +Signed-off-by: Greg Kroah-Hartman +--- + arch/sparc/kernel/of_device_32.c | 1 + + arch/sparc/kernel/of_device_64.c | 1 + + 2 files changed, 2 insertions(+) + +--- a/arch/sparc/kernel/of_device_32.c ++++ b/arch/sparc/kernel/of_device_32.c +@@ -387,6 +387,7 @@ static struct platform_device * __init s + + if (of_device_register(op)) { + printk("%pOF: Could not register of device.\n", dp); ++ put_device(&op->dev); + kfree(op); + op = NULL; + } +--- a/arch/sparc/kernel/of_device_64.c ++++ b/arch/sparc/kernel/of_device_64.c +@@ -680,6 +680,7 @@ static struct platform_device * __init s + + if (of_device_register(op)) { + printk("%pOF: Could not register of device.\n", dp); ++ put_device(&op->dev); + kfree(op); + op = NULL; + } diff --git a/queue-5.10/sparc64-fix-hugetlb-for-sun4u.patch b/queue-5.10/sparc64-fix-hugetlb-for-sun4u.patch new file mode 100644 index 0000000000..2bc1685083 --- /dev/null +++ b/queue-5.10/sparc64-fix-hugetlb-for-sun4u.patch @@ -0,0 +1,64 @@ +From 6fd44a481b3c6111e4801cec964627791d0f3ec5 Mon Sep 17 00:00:00 2001 +From: Anthony Yznaga +Date: Tue, 15 Jul 2025 18:24:46 -0700 +Subject: sparc64: fix hugetlb for sun4u + +From: Anthony Yznaga + +commit 6fd44a481b3c6111e4801cec964627791d0f3ec5 upstream. + +An attempt to exercise sparc hugetlb code in a sun4u-based guest +running under qemu results in the guest hanging due to being stuck +in a trap loop. This is due to invalid hugetlb TTEs being installed +that do not have the expected _PAGE_PMD_HUGE and page size bits set. +Although the breakage has gone apparently unnoticed for several years, +fix it now so there is the option to exercise sparc hugetlb code under +qemu. This can be useful because sun4v support in qemu does not support +linux guests currently and sun4v-based hardware resources may not be +readily available. + +Fix tested with a 6.15.2 and 6.16-rc6 kernels by running libhugetlbfs +tests on a qemu guest running Debian 13. + +Fixes: c7d9f77d33a7 ("sparc64: Multi-page size support") +Cc: stable@vger.kernel.org +Signed-off-by: Anthony Yznaga +Tested-by: John Paul Adrian Glaubitz +Reviewed-by: John Paul Adrian Glaubitz +Reviewed-by: Andreas Larsson +Link: https://lore.kernel.org/r/20250716012446.10357-1-anthony.yznaga@oracle.com +Signed-off-by: Andreas Larsson +Signed-off-by: Greg Kroah-Hartman +--- + arch/sparc/mm/hugetlbpage.c | 20 ++++++++++++++++++++ + 1 file changed, 20 insertions(+) + +--- a/arch/sparc/mm/hugetlbpage.c ++++ b/arch/sparc/mm/hugetlbpage.c +@@ -133,6 +133,26 @@ hugetlb_get_unmapped_area(struct file *f + + static pte_t sun4u_hugepage_shift_to_tte(pte_t entry, unsigned int shift) + { ++ unsigned long hugepage_size = _PAGE_SZ4MB_4U; ++ ++ pte_val(entry) = pte_val(entry) & ~_PAGE_SZALL_4U; ++ ++ switch (shift) { ++ case HPAGE_256MB_SHIFT: ++ hugepage_size = _PAGE_SZ256MB_4U; ++ pte_val(entry) |= _PAGE_PMD_HUGE; ++ break; ++ case HPAGE_SHIFT: ++ pte_val(entry) |= _PAGE_PMD_HUGE; ++ break; ++ case HPAGE_64K_SHIFT: ++ hugepage_size = _PAGE_SZ64K_4U; ++ break; ++ default: ++ WARN_ONCE(1, "unsupported hugepage shift=%u\n", shift); ++ } ++ ++ pte_val(entry) = pte_val(entry) | hugepage_size; + return entry; + } + diff --git a/queue-5.10/spi-cadence-quadspi-flush-posted-register-writes-before-indac-access.patch b/queue-5.10/spi-cadence-quadspi-flush-posted-register-writes-before-indac-access.patch new file mode 100644 index 0000000000..c95a4b0607 --- /dev/null +++ b/queue-5.10/spi-cadence-quadspi-flush-posted-register-writes-before-indac-access.patch @@ -0,0 +1,52 @@ +From 29e0b471ccbd674d20d4bbddea1a51e7105212c5 Mon Sep 17 00:00:00 2001 +From: Pratyush Yadav +Date: Sat, 6 Sep 2025 00:29:55 +0530 +Subject: spi: cadence-quadspi: Flush posted register writes before INDAC access + +From: Pratyush Yadav + +commit 29e0b471ccbd674d20d4bbddea1a51e7105212c5 upstream. + +cqspi_indirect_read_execute() and cqspi_indirect_write_execute() first +set the enable bit on APB region and then start reading/writing to the +AHB region. On TI K3 SoCs these regions lie on different endpoints. This +means that the order of the two operations is not guaranteed, and they +might be reordered at the interconnect level. + +It is possible for the AHB write to be executed before the APB write to +enable the indirect controller, causing the transaction to be invalid +and the write erroring out. Read back the APB region write before +accessing the AHB region to make sure the write got flushed and the race +condition is eliminated. + +Fixes: 140623410536 ("mtd: spi-nor: Add driver for Cadence Quad SPI Flash Controller") +CC: stable@vger.kernel.org +Reviewed-by: Pratyush Yadav +Signed-off-by: Pratyush Yadav +Signed-off-by: Santhosh Kumar K +Message-ID: <20250905185958.3575037-2-s-k6@ti.com> +Signed-off-by: Mark Brown +Signed-off-by: Greg Kroah-Hartman +--- + drivers/spi/spi-cadence-quadspi.c | 3 +++ + 1 file changed, 3 insertions(+) + +--- a/drivers/spi/spi-cadence-quadspi.c ++++ b/drivers/spi/spi-cadence-quadspi.c +@@ -502,6 +502,7 @@ static int cqspi_indirect_read_execute(s + reinit_completion(&cqspi->transfer_complete); + writel(CQSPI_REG_INDIRECTRD_START_MASK, + reg_base + CQSPI_REG_INDIRECTRD); ++ readl(reg_base + CQSPI_REG_INDIRECTRD); /* Flush posted write. */ + + while (remaining > 0) { + if (!wait_for_completion_timeout(&cqspi->transfer_complete, +@@ -611,6 +612,8 @@ static int cqspi_indirect_write_execute( + reinit_completion(&cqspi->transfer_complete); + writel(CQSPI_REG_INDIRECTWR_START_MASK, + reg_base + CQSPI_REG_INDIRECTWR); ++ readl(reg_base + CQSPI_REG_INDIRECTWR); /* Flush posted write. */ ++ + /* + * As per 66AK2G02 TRM SPRUHY8F section 11.15.5.3 Indirect Access + * Controller programming sequence, couple of cycles of diff --git a/queue-5.10/x86-umip-check-that-the-instruction-opcode-is-at-least-two-bytes.patch b/queue-5.10/x86-umip-check-that-the-instruction-opcode-is-at-least-two-bytes.patch new file mode 100644 index 0000000000..9dbdb7ca9e --- /dev/null +++ b/queue-5.10/x86-umip-check-that-the-instruction-opcode-is-at-least-two-bytes.patch @@ -0,0 +1,56 @@ +From 32278c677947ae2f042c9535674a7fff9a245dd3 Mon Sep 17 00:00:00 2001 +From: Sean Christopherson +Date: Fri, 8 Aug 2025 10:23:56 -0700 +Subject: x86/umip: Check that the instruction opcode is at least two bytes + +From: Sean Christopherson + +commit 32278c677947ae2f042c9535674a7fff9a245dd3 upstream. + +When checking for a potential UMIP violation on #GP, verify the decoder found +at least two opcode bytes to avoid false positives when the kernel encounters +an unknown instruction that starts with 0f. Because the array of opcode.bytes +is zero-initialized by insn_init(), peeking at bytes[1] will misinterpret +garbage as a potential SLDT or STR instruction, and can incorrectly trigger +emulation. + +E.g. if a VPALIGNR instruction + + 62 83 c5 05 0f 08 ff vpalignr xmm17{k5},xmm23,XMMWORD PTR [r8],0xff + +hits a #GP, the kernel emulates it as STR and squashes the #GP (and corrupts +the userspace code stream). + +Arguably the check should look for exactly two bytes, but no three byte +opcodes use '0f 00 xx' or '0f 01 xx' as an escape, i.e. it should be +impossible to get a false positive if the first two opcode bytes match '0f 00' +or '0f 01'. Go with a more conservative check with respect to the existing +code to minimize the chances of breaking userspace, e.g. due to decoder +weirdness. + +Analyzed by Nick Bray . + +Fixes: 1e5db223696a ("x86/umip: Add emulation code for UMIP instructions") +Reported-by: Dan Snyder +Signed-off-by: Sean Christopherson +Signed-off-by: Borislav Petkov (AMD) +Acked-by: Peter Zijlstra (Intel) +Cc: stable@vger.kernel.org +Signed-off-by: Greg Kroah-Hartman +--- + arch/x86/kernel/umip.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +--- a/arch/x86/kernel/umip.c ++++ b/arch/x86/kernel/umip.c +@@ -156,8 +156,8 @@ static int identify_insn(struct insn *in + if (!insn->modrm.nbytes) + return -EINVAL; + +- /* All the instructions of interest start with 0x0f. */ +- if (insn->opcode.bytes[0] != 0xf) ++ /* The instructions of interest have 2-byte opcodes: 0F 00 or 0F 01. */ ++ if (insn->opcode.nbytes < 2 || insn->opcode.bytes[0] != 0xf) + return -EINVAL; + + if (insn->opcode.bytes[1] == 0x1) { diff --git a/queue-5.10/x86-umip-fix-decoding-of-register-forms-of-0f-01-sgdt-and-sidt-aliases.patch b/queue-5.10/x86-umip-fix-decoding-of-register-forms-of-0f-01-sgdt-and-sidt-aliases.patch new file mode 100644 index 0000000000..df0f3ea3c0 --- /dev/null +++ b/queue-5.10/x86-umip-fix-decoding-of-register-forms-of-0f-01-sgdt-and-sidt-aliases.patch @@ -0,0 +1,48 @@ +From 27b1fd62012dfe9d3eb8ecde344d7aa673695ecf Mon Sep 17 00:00:00 2001 +From: Sean Christopherson +Date: Fri, 8 Aug 2025 10:23:57 -0700 +Subject: x86/umip: Fix decoding of register forms of 0F 01 (SGDT and SIDT aliases) + +From: Sean Christopherson + +commit 27b1fd62012dfe9d3eb8ecde344d7aa673695ecf upstream. + +Filter out the register forms of 0F 01 when determining whether or not to +emulate in response to a potential UMIP violation #GP, as SGDT and SIDT only +accept memory operands. The register variants of 0F 01 are used to encode +instructions for things like VMX and SGX, i.e. not checking the Mod field +would cause the kernel to incorrectly emulate on #GP, e.g. due to a CPL +violation on VMLAUNCH. + +Fixes: 1e5db223696a ("x86/umip: Add emulation code for UMIP instructions") +Signed-off-by: Sean Christopherson +Signed-off-by: Borislav Petkov (AMD) +Acked-by: Peter Zijlstra (Intel) +Cc: stable@vger.kernel.org +Signed-off-by: Greg Kroah-Hartman +--- + arch/x86/kernel/umip.c | 11 +++++++++++ + 1 file changed, 11 insertions(+) + +--- a/arch/x86/kernel/umip.c ++++ b/arch/x86/kernel/umip.c +@@ -163,8 +163,19 @@ static int identify_insn(struct insn *in + if (insn->opcode.bytes[1] == 0x1) { + switch (X86_MODRM_REG(insn->modrm.value)) { + case 0: ++ /* The reg form of 0F 01 /0 encodes VMX instructions. */ ++ if (X86_MODRM_MOD(insn->modrm.value) == 3) ++ return -EINVAL; ++ + return UMIP_INST_SGDT; + case 1: ++ /* ++ * The reg form of 0F 01 /1 encodes MONITOR/MWAIT, ++ * STAC/CLAC, and ENCLS. ++ */ ++ if (X86_MODRM_MOD(insn->modrm.value) == 3) ++ return -EINVAL; ++ + return UMIP_INST_SIDT; + case 4: + return UMIP_INST_SMSW;