--- /dev/null
+From 168e24966f10ff635b0ec9728aa71833bf850ee5 Mon Sep 17 00:00:00 2001
+From: Peter Griffin <peter.griffin@linaro.org>
+Date: Mon, 6 Jan 2025 14:57:46 +0000
+Subject: arm64: dts: exynos: gs101: disable pinctrl_gsacore node
+
+From: Peter Griffin <peter.griffin@linaro.org>
+
+commit 168e24966f10ff635b0ec9728aa71833bf850ee5 upstream.
+
+gsacore registers are not accessible from normal world.
+
+Disable this node, so that the suspend/resume callbacks
+in the pinctrl driver don't cause a Serror attempting to
+access the registers.
+
+Fixes: ea89fdf24fd9 ("arm64: dts: exynos: google: Add initial Google gs101 SoC support")
+Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
+To: Rob Herring <robh@kernel.org>
+To: Krzysztof Kozlowski <krzk+dt@kernel.org>
+To: Conor Dooley <conor+dt@kernel.org>
+To: Alim Akhtar <alim.akhtar@samsung.com>
+Cc: linux-arm-kernel@lists.infradead.org
+Cc: linux-samsung-soc@vger.kernel.org
+Cc: devicetree@vger.kernel.org
+Cc: linux-kernel@vger.kernel.org
+Cc: tudor.ambarus@linaro.org
+Cc: andre.draszik@linaro.org
+Cc: kernel-team@android.com
+Cc: willmcvicker@google.com
+Cc: stable@vger.kernel.org
+Link: https://lore.kernel.org/r/20250106-contrib-pg-pinctrl_gsacore_disable-v1-1-d3fc88a48aed@linaro.org
+Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/arm64/boot/dts/exynos/google/gs101.dtsi | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/arch/arm64/boot/dts/exynos/google/gs101.dtsi
++++ b/arch/arm64/boot/dts/exynos/google/gs101.dtsi
+@@ -1451,6 +1451,7 @@
+ /* TODO: update once support for this CMU exists */
+ clocks = <0>;
+ clock-names = "pclk";
++ status = "disabled";
+ };
+
+ cmu_top: clock-controller@1e080000 {
--- /dev/null
+From 46ad36002088eff8fc5cae200aa42ae9f9310ddd Mon Sep 17 00:00:00 2001
+From: Chen-Yu Tsai <wenst@chromium.org>
+Date: Wed, 8 Jan 2025 16:34:22 +0800
+Subject: arm64: dts: mediatek: mt8173: Fix disp-pwm compatible string
+
+From: Chen-Yu Tsai <wenst@chromium.org>
+
+commit 46ad36002088eff8fc5cae200aa42ae9f9310ddd upstream.
+
+The MT8173 disp-pwm device should have only one compatible string, based
+on the following DT validation error:
+
+ arch/arm64/boot/dts/mediatek/mt8173-elm.dtb: pwm@1401e000: compatible: 'oneOf' conditional failed, one must be fixed:
+ ['mediatek,mt8173-disp-pwm', 'mediatek,mt6595-disp-pwm'] is too long
+ 'mediatek,mt8173-disp-pwm' is not one of ['mediatek,mt6795-disp-pwm', 'mediatek,mt8167-disp-pwm']
+ 'mediatek,mt8173-disp-pwm' is not one of ['mediatek,mt8186-disp-pwm', 'mediatek,mt8188-disp-pwm', 'mediatek,mt8192-disp-pwm', 'mediatek,mt8195-disp-pwm', 'mediatek,mt8365-disp-pwm']
+ 'mediatek,mt8173-disp-pwm' was expected
+ 'mediatek,mt8183-disp-pwm' was expected
+ from schema $id: http://devicetree.org/schemas/pwm/mediatek,pwm-disp.yaml#
+ arch/arm64/boot/dts/mediatek/mt8173-elm.dtb: pwm@1401f000: compatible: 'oneOf' conditional failed, one must be fixed:
+ ['mediatek,mt8173-disp-pwm', 'mediatek,mt6595-disp-pwm'] is too long
+ 'mediatek,mt8173-disp-pwm' is not one of ['mediatek,mt6795-disp-pwm', 'mediatek,mt8167-disp-pwm']
+ 'mediatek,mt8173-disp-pwm' is not one of ['mediatek,mt8186-disp-pwm', 'mediatek,mt8188-disp-pwm', 'mediatek,mt8192-disp-pwm', 'mediatek,mt8195-disp-pwm', 'mediatek,mt8365-disp-pwm']
+ 'mediatek,mt8173-disp-pwm' was expected
+ 'mediatek,mt8183-disp-pwm' was expected
+ from schema $id: http://devicetree.org/schemas/pwm/mediatek,pwm-disp.yaml#
+
+Drop the extra "mediatek,mt6595-disp-pwm" compatible string.
+
+Fixes: 61aee9342514 ("arm64: dts: mt8173: add MT8173 display PWM driver support node")
+Cc: YH Huang <yh.huang@mediatek.com>
+Cc: stable@vger.kernel.org # v4.5+
+Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
+Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
+Link: https://lore.kernel.org/r/20250108083424.2732375-2-wenst@chromium.org
+Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/arm64/boot/dts/mediatek/mt8173.dtsi | 6 ++----
+ 1 file changed, 2 insertions(+), 4 deletions(-)
+
+--- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
++++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
+@@ -1255,8 +1255,7 @@
+ };
+
+ pwm0: pwm@1401e000 {
+- compatible = "mediatek,mt8173-disp-pwm",
+- "mediatek,mt6595-disp-pwm";
++ compatible = "mediatek,mt8173-disp-pwm";
+ reg = <0 0x1401e000 0 0x1000>;
+ #pwm-cells = <2>;
+ clocks = <&mmsys CLK_MM_DISP_PWM026M>,
+@@ -1266,8 +1265,7 @@
+ };
+
+ pwm1: pwm@1401f000 {
+- compatible = "mediatek,mt8173-disp-pwm",
+- "mediatek,mt6595-disp-pwm";
++ compatible = "mediatek,mt8173-disp-pwm";
+ reg = <0 0x1401f000 0 0x1000>;
+ #pwm-cells = <2>;
+ clocks = <&mmsys CLK_MM_DISP_PWM126M>,
--- /dev/null
+From 89f43e1ce6f60d4f44399059595ac47f7a90a393 Mon Sep 17 00:00:00 2001
+From: Zhenhua Huang <quic_zhenhuah@quicinc.com>
+Date: Fri, 21 Mar 2025 15:00:19 +0800
+Subject: arm64: mm: Correct the update of max_pfn
+
+From: Zhenhua Huang <quic_zhenhuah@quicinc.com>
+
+commit 89f43e1ce6f60d4f44399059595ac47f7a90a393 upstream.
+
+Hotplugged memory can be smaller than the original memory. For example,
+on my target:
+
+root@genericarmv8:~# cat /sys/kernel/debug/memblock/memory
+ 0: 0x0000000064005000..0x0000000064023fff 0 NOMAP
+ 1: 0x0000000064400000..0x00000000647fffff 0 NOMAP
+ 2: 0x0000000068000000..0x000000006fffffff 0 DRV_MNG
+ 3: 0x0000000088800000..0x0000000094ffefff 0 NONE
+ 4: 0x0000000094fff000..0x0000000094ffffff 0 NOMAP
+max_pfn will affect read_page_owner. Therefore, it should first compare and
+then select the larger value for max_pfn.
+
+Fixes: 8fac67ca236b ("arm64: mm: update max_pfn after memory hotplug")
+Cc: <stable@vger.kernel.org> # 6.1.x
+Signed-off-by: Zhenhua Huang <quic_zhenhuah@quicinc.com>
+Acked-by: David Hildenbrand <david@redhat.com>
+Reviewed-by: Anshuman Khandual <anshuman.khandual@arm.com>
+Link: https://lore.kernel.org/r/20250321070019.1271859-1-quic_zhenhuah@quicinc.com
+Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/arm64/mm/mmu.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/arch/arm64/mm/mmu.c
++++ b/arch/arm64/mm/mmu.c
+@@ -1360,7 +1360,8 @@ int arch_add_memory(int nid, u64 start,
+ __remove_pgd_mapping(swapper_pg_dir,
+ __phys_to_virt(start), size);
+ else {
+- max_pfn = PFN_UP(start + size);
++ /* Address of hotplugged memory can be smaller */
++ max_pfn = max(max_pfn, PFN_UP(start + size));
+ max_low_pfn = max_pfn;
+ }
+
--- /dev/null
+From a13bfa4fe0d6949cea14718df2d1fe84c38cd113 Mon Sep 17 00:00:00 2001
+From: Keir Fraser <keirf@google.com>
+Date: Wed, 26 Mar 2025 11:04:47 +0000
+Subject: arm64: mops: Do not dereference src reg for a set operation
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Keir Fraser <keirf@google.com>
+
+commit a13bfa4fe0d6949cea14718df2d1fe84c38cd113 upstream.
+
+The source register is not used for SET* and reading it can result in
+a UBSAN out-of-bounds array access error, specifically when the MOPS
+exception is taken from a SET* sequence with XZR (reg 31) as the
+source. Architecturally this is the only case where a src/dst/size
+field in the ESR can be reported as 31.
+
+Prior to 2de451a329cf662b the code in do_el0_mops() was benign as the
+use of pt_regs_read_reg() prevented the out-of-bounds access.
+
+Fixes: 2de451a329cf ("KVM: arm64: Add handler for MOPS exceptions")
+Cc: <stable@vger.kernel.org> # 6.12.x
+Cc: Kristina Martsenko <kristina.martsenko@arm.com>
+Cc: Will Deacon <will@kernel.org>
+Cc: stable@vger.kernel.org
+Reviewed-by: Marc Zyngier <maz@kernel.org>
+Signed-off-by: Keir Fraser <keirf@google.com>
+Reviewed-by: Kristina Martšenko <kristina.martsenko@arm.com>
+Acked-by: Mark Rutland <mark.rutland@arm.com>
+Link: https://lore.kernel.org/r/20250326110448.3792396-1-keirf@google.com
+Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/arm64/include/asm/traps.h | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/arch/arm64/include/asm/traps.h b/arch/arm64/include/asm/traps.h
+index d780d1bd2eac..82cf1f879c61 100644
+--- a/arch/arm64/include/asm/traps.h
++++ b/arch/arm64/include/asm/traps.h
+@@ -109,10 +109,9 @@ static inline void arm64_mops_reset_regs(struct user_pt_regs *regs, unsigned lon
+ int dstreg = ESR_ELx_MOPS_ISS_DESTREG(esr);
+ int srcreg = ESR_ELx_MOPS_ISS_SRCREG(esr);
+ int sizereg = ESR_ELx_MOPS_ISS_SIZEREG(esr);
+- unsigned long dst, src, size;
++ unsigned long dst, size;
+
+ dst = regs->regs[dstreg];
+- src = regs->regs[srcreg];
+ size = regs->regs[sizereg];
+
+ /*
+@@ -129,6 +128,7 @@ static inline void arm64_mops_reset_regs(struct user_pt_regs *regs, unsigned lon
+ }
+ } else {
+ /* CPY* instruction */
++ unsigned long src = regs->regs[srcreg];
+ if (!(option_a ^ wrong_option)) {
+ /* Format is from Option B */
+ if (regs->pstate & PSR_N_BIT) {
+--
+2.49.0
+
--- /dev/null
+From bb8a3ad25f098b6ea9b1d0f522427b4ad53a7bba Mon Sep 17 00:00:00 2001
+From: Ninad Malwade <nmalwade@nvidia.com>
+Date: Thu, 6 Feb 2025 22:40:34 +0000
+Subject: arm64: tegra: Remove the Orin NX/Nano suspend key
+
+From: Ninad Malwade <nmalwade@nvidia.com>
+
+commit bb8a3ad25f098b6ea9b1d0f522427b4ad53a7bba upstream.
+
+As per the Orin Nano Dev Kit schematic, GPIO_G.02 is not available
+on this device family. It should not be used at all on Orin NX/Nano.
+Having this unused pin mapped as the suspend key can lead to
+unpredictable behavior for low power modes.
+
+Orin NX/Nano uses GPIO_EE.04 as both a "power" button and a "suspend"
+button. However, we cannot have two gpio-keys mapped to the same
+GPIO. Therefore remove the "suspend" key.
+
+Cc: stable@vger.kernel.org
+Fixes: e63472eda5ea ("arm64: tegra: Support Jetson Orin NX reference platform")
+Signed-off-by: Ninad Malwade <nmalwade@nvidia.com>
+Signed-off-by: Ivy Huang <yijuh@nvidia.com>
+Link: https://lore.kernel.org/r/20250206224034.3691397-1-yijuh@nvidia.com
+Signed-off-by: Thierry Reding <treding@nvidia.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/arm64/boot/dts/nvidia/tegra234-p3768-0000+p3767.dtsi | 7 -------
+ 1 file changed, 7 deletions(-)
+
+--- a/arch/arm64/boot/dts/nvidia/tegra234-p3768-0000+p3767.dtsi
++++ b/arch/arm64/boot/dts/nvidia/tegra234-p3768-0000+p3767.dtsi
+@@ -227,13 +227,6 @@
+ wakeup-event-action = <EV_ACT_ASSERTED>;
+ wakeup-source;
+ };
+-
+- key-suspend {
+- label = "Suspend";
+- gpios = <&gpio TEGRA234_MAIN_GPIO(G, 2) GPIO_ACTIVE_LOW>;
+- linux,input-type = <EV_KEY>;
+- linux,code = <KEY_SLEEP>;
+- };
+ };
+
+ fan: pwm-fan {
--- /dev/null
+From 276822a00db3c1061382b41e72cafc09d6a0ec30 Mon Sep 17 00:00:00 2001
+From: Herve Codina <herve.codina@bootlin.com>
+Date: Wed, 22 Jan 2025 10:19:14 +0100
+Subject: backlight: led_bl: Hold led_access lock when calling led_sysfs_disable()
+
+From: Herve Codina <herve.codina@bootlin.com>
+
+commit 276822a00db3c1061382b41e72cafc09d6a0ec30 upstream.
+
+Lockdep detects the following issue on led-backlight removal:
+ [ 142.315935] ------------[ cut here ]------------
+ [ 142.315954] WARNING: CPU: 2 PID: 292 at drivers/leds/led-core.c:455 led_sysfs_enable+0x54/0x80
+ ...
+ [ 142.500725] Call trace:
+ [ 142.503176] led_sysfs_enable+0x54/0x80 (P)
+ [ 142.507370] led_bl_remove+0x80/0xa8 [led_bl]
+ [ 142.511742] platform_remove+0x30/0x58
+ [ 142.515501] device_remove+0x54/0x90
+ ...
+
+Indeed, led_sysfs_enable() has to be called with the led_access
+lock held.
+
+Hold the lock when calling led_sysfs_disable().
+
+Fixes: ae232e45acf9 ("backlight: add led-backlight driver")
+Cc: stable@vger.kernel.org
+Signed-off-by: Herve Codina <herve.codina@bootlin.com>
+Link: https://lore.kernel.org/r/20250122091914.309533-1-herve.codina@bootlin.com
+Signed-off-by: Lee Jones <lee@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/video/backlight/led_bl.c | 5 ++++-
+ 1 file changed, 4 insertions(+), 1 deletion(-)
+
+--- a/drivers/video/backlight/led_bl.c
++++ b/drivers/video/backlight/led_bl.c
+@@ -229,8 +229,11 @@ static void led_bl_remove(struct platfor
+ backlight_device_unregister(bl);
+
+ led_bl_power_off(priv);
+- for (i = 0; i < priv->nb_leds; i++)
++ for (i = 0; i < priv->nb_leds; i++) {
++ mutex_lock(&priv->leds[i]->led_access);
+ led_sysfs_enable(priv->leds[i]);
++ mutex_unlock(&priv->leds[i]->led_access);
++ }
+ }
+
+ static const struct of_device_id led_bl_of_match[] = {
--- /dev/null
+From bd496a44f041da9ef3afe14d1d6193d460424e91 Mon Sep 17 00:00:00 2001
+From: Manjunatha Venkatesh <manjunatha.venkatesh@nxp.com>
+Date: Wed, 26 Mar 2025 18:00:46 +0530
+Subject: i3c: Add NULL pointer check in i3c_master_queue_ibi()
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Manjunatha Venkatesh <manjunatha.venkatesh@nxp.com>
+
+commit bd496a44f041da9ef3afe14d1d6193d460424e91 upstream.
+
+The I3C master driver may receive an IBI from a target device that has not
+been probed yet. In such cases, the master calls `i3c_master_queue_ibi()`
+to queue an IBI work task, leading to "Unable to handle kernel read from
+unreadable memory" and resulting in a kernel panic.
+
+Typical IBI handling flow:
+1. The I3C master scans target devices and probes their respective drivers.
+2. The target device driver calls `i3c_device_request_ibi()` to enable IBI
+ and assigns `dev->ibi = ibi`.
+3. The I3C master receives an IBI from the target device and calls
+ `i3c_master_queue_ibi()` to queue the target device driver’s IBI
+ handler task.
+
+However, since target device events are asynchronous to the I3C probe
+sequence, step 3 may occur before step 2, causing `dev->ibi` to be `NULL`,
+leading to a kernel panic.
+
+Add a NULL pointer check in `i3c_master_queue_ibi()` to prevent accessing
+an uninitialized `dev->ibi`, ensuring stability.
+
+Fixes: 3a379bbcea0af ("i3c: Add core I3C infrastructure")
+Cc: stable@vger.kernel.org
+Link: https://lore.kernel.org/lkml/Z9gjGYudiYyl3bSe@lizhi-Precision-Tower-5810/
+Signed-off-by: Manjunatha Venkatesh <manjunatha.venkatesh@nxp.com>
+Reviewed-by: Frank Li <Frank.Li@nxp.com>
+Link: https://lore.kernel.org/r/20250326123047.2797946-1-manjunatha.venkatesh@nxp.com
+Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/i3c/master.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/drivers/i3c/master.c
++++ b/drivers/i3c/master.c
+@@ -2553,6 +2553,9 @@ static void i3c_master_unregister_i3c_de
+ */
+ void i3c_master_queue_ibi(struct i3c_dev_desc *dev, struct i3c_ibi_slot *slot)
+ {
++ if (!dev->ibi || !slot)
++ return;
++
+ atomic_inc(&dev->ibi->pending_ibis);
+ queue_work(dev->ibi->wq, &slot->work);
+ }
--- /dev/null
+From c06acf7143bddaa3c0f7bedd8b99e48f6acb85c3 Mon Sep 17 00:00:00 2001
+From: Stanley Chu <yschu@nuvoton.com>
+Date: Tue, 18 Mar 2025 13:36:05 +0800
+Subject: i3c: master: svc: Use readsb helper for reading MDB
+
+From: Stanley Chu <yschu@nuvoton.com>
+
+commit c06acf7143bddaa3c0f7bedd8b99e48f6acb85c3 upstream.
+
+The target can send the MDB byte followed by additional data bytes.
+The readl on MRDATAB reads one actual byte, but the readsl advances
+the destination pointer by 4 bytes. This causes the subsequent payload
+to be copied to wrong position in the destination buffer.
+
+Cc: stable@kernel.org
+Fixes: dd3c52846d59 ("i3c: master: svc: Add Silvaco I3C master driver")
+Signed-off-by: Stanley Chu <yschu@nuvoton.com>
+Reviewed-by: Frank Li <Frank.Li@nxp.com>
+Link: https://lore.kernel.org/r/20250318053606.3087121-3-yschu@nuvoton.com
+Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/i3c/master/svc-i3c-master.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/i3c/master/svc-i3c-master.c
++++ b/drivers/i3c/master/svc-i3c-master.c
+@@ -378,7 +378,7 @@ static int svc_i3c_master_handle_ibi(str
+ slot->len < SVC_I3C_FIFO_SIZE) {
+ mdatactrl = readl(master->regs + SVC_I3C_MDATACTRL);
+ count = SVC_I3C_MDATACTRL_RXCOUNT(mdatactrl);
+- readsl(master->regs + SVC_I3C_MRDATAB, buf, count);
++ readsb(master->regs + SVC_I3C_MRDATAB, buf, count);
+ slot->len += count;
+ buf += count;
+ }
--- /dev/null
+From 5b3cd801155f0b34b0b95942a5b057c9b8cad33e Mon Sep 17 00:00:00 2001
+From: Mimi Zohar <zohar@linux.ibm.com>
+Date: Mon, 27 Jan 2025 10:24:13 -0500
+Subject: ima: limit the number of open-writers integrity violations
+
+From: Mimi Zohar <zohar@linux.ibm.com>
+
+commit 5b3cd801155f0b34b0b95942a5b057c9b8cad33e upstream.
+
+Each time a file in policy, that is already opened for write, is opened
+for read, an open-writers integrity violation audit message is emitted
+and a violation record is added to the IMA measurement list. This
+occurs even if an open-writers violation has already been recorded.
+
+Limit the number of open-writers integrity violations for an existing
+file open for write to one. After the existing file open for write
+closes (__fput), subsequent open-writers integrity violations may be
+emitted.
+
+Cc: stable@vger.kernel.org # applies cleanly up to linux-6.6
+Tested-by: Stefan Berger <stefanb@linux.ibm.com>
+Reviewed-by: Petr Vorel <pvorel@suse.cz>
+Tested-by: Petr Vorel <pvorel@suse.cz>
+Reviewed-by: Roberto Sassu <roberto.sassu@huawei.com>
+Signed-off-by: Mimi Zohar <zohar@linux.ibm.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ security/integrity/ima/ima.h | 1 +
+ security/integrity/ima/ima_main.c | 11 +++++++++--
+ 2 files changed, 10 insertions(+), 2 deletions(-)
+
+--- a/security/integrity/ima/ima.h
++++ b/security/integrity/ima/ima.h
+@@ -182,6 +182,7 @@ struct ima_kexec_hdr {
+ #define IMA_CHANGE_ATTR 2
+ #define IMA_DIGSIG 3
+ #define IMA_MUST_MEASURE 4
++#define IMA_EMITTED_OPENWRITERS 5
+
+ /* IMA integrity metadata associated with an inode */
+ struct ima_iint_cache {
+--- a/security/integrity/ima/ima_main.c
++++ b/security/integrity/ima/ima_main.c
+@@ -137,8 +137,13 @@ static void ima_rdwr_violation_check(str
+ } else {
+ if (must_measure)
+ set_bit(IMA_MUST_MEASURE, &iint->atomic_flags);
+- if (inode_is_open_for_write(inode) && must_measure)
+- send_writers = true;
++
++ /* Limit number of open_writers violations */
++ if (inode_is_open_for_write(inode) && must_measure) {
++ if (!test_and_set_bit(IMA_EMITTED_OPENWRITERS,
++ &iint->atomic_flags))
++ send_writers = true;
++ }
+ }
+
+ if (!send_tomtou && !send_writers)
+@@ -167,6 +172,8 @@ static void ima_check_last_writer(struct
+ if (atomic_read(&inode->i_writecount) == 1) {
+ struct kstat stat;
+
++ clear_bit(IMA_EMITTED_OPENWRITERS, &iint->atomic_flags);
++
+ update = test_and_clear_bit(IMA_UPDATE_XATTR,
+ &iint->atomic_flags);
+ if ((iint->flags & IMA_NEW_FILE) ||
--- /dev/null
+From a414016218ca97140171aa3bb926b02e1f68c2cc Mon Sep 17 00:00:00 2001
+From: Mimi Zohar <zohar@linux.ibm.com>
+Date: Mon, 27 Jan 2025 10:45:48 -0500
+Subject: ima: limit the number of ToMToU integrity violations
+
+From: Mimi Zohar <zohar@linux.ibm.com>
+
+commit a414016218ca97140171aa3bb926b02e1f68c2cc upstream.
+
+Each time a file in policy, that is already opened for read, is opened
+for write, a Time-of-Measure-Time-of-Use (ToMToU) integrity violation
+audit message is emitted and a violation record is added to the IMA
+measurement list. This occurs even if a ToMToU violation has already
+been recorded.
+
+Limit the number of ToMToU integrity violations per file open for read.
+
+Note: The IMA_MAY_EMIT_TOMTOU atomic flag must be set from the reader
+side based on policy. This may result in a per file open for read
+ToMToU violation.
+
+Since IMA_MUST_MEASURE is only used for violations, rename the atomic
+IMA_MUST_MEASURE flag to IMA_MAY_EMIT_TOMTOU.
+
+Cc: stable@vger.kernel.org # applies cleanly up to linux-6.6
+Tested-by: Stefan Berger <stefanb@linux.ibm.com>
+Reviewed-by: Petr Vorel <pvorel@suse.cz>
+Tested-by: Petr Vorel <pvorel@suse.cz>
+Reviewed-by: Roberto Sassu <roberto.sassu@huawei.com>
+Signed-off-by: Mimi Zohar <zohar@linux.ibm.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ security/integrity/ima/ima.h | 2 +-
+ security/integrity/ima/ima_main.c | 7 ++++---
+ 2 files changed, 5 insertions(+), 4 deletions(-)
+
+--- a/security/integrity/ima/ima.h
++++ b/security/integrity/ima/ima.h
+@@ -181,7 +181,7 @@ struct ima_kexec_hdr {
+ #define IMA_UPDATE_XATTR 1
+ #define IMA_CHANGE_ATTR 2
+ #define IMA_DIGSIG 3
+-#define IMA_MUST_MEASURE 4
++#define IMA_MAY_EMIT_TOMTOU 4
+ #define IMA_EMITTED_OPENWRITERS 5
+
+ /* IMA integrity metadata associated with an inode */
+--- a/security/integrity/ima/ima_main.c
++++ b/security/integrity/ima/ima_main.c
+@@ -129,14 +129,15 @@ static void ima_rdwr_violation_check(str
+ if (atomic_read(&inode->i_readcount) && IS_IMA(inode)) {
+ if (!iint)
+ iint = ima_iint_find(inode);
++
+ /* IMA_MEASURE is set from reader side */
+- if (iint && test_bit(IMA_MUST_MEASURE,
+- &iint->atomic_flags))
++ if (iint && test_and_clear_bit(IMA_MAY_EMIT_TOMTOU,
++ &iint->atomic_flags))
+ send_tomtou = true;
+ }
+ } else {
+ if (must_measure)
+- set_bit(IMA_MUST_MEASURE, &iint->atomic_flags);
++ set_bit(IMA_MAY_EMIT_TOMTOU, &iint->atomic_flags);
+
+ /* Limit number of open_writers violations */
+ if (inode_is_open_for_write(inode) && must_measure) {
--- /dev/null
+From e6eff39dd0fe4190c6146069cc16d160e71d1148 Mon Sep 17 00:00:00 2001
+From: Jan Kara <jack@suse.cz>
+Date: Thu, 6 Feb 2025 10:46:58 +0100
+Subject: jbd2: remove wrong sb->s_sequence check
+
+From: Jan Kara <jack@suse.cz>
+
+commit e6eff39dd0fe4190c6146069cc16d160e71d1148 upstream.
+
+Journal emptiness is not determined by sb->s_sequence == 0 but rather by
+sb->s_start == 0 (which is set a few lines above). Furthermore 0 is a
+valid transaction ID so the check can spuriously trigger. Remove the
+invalid WARN_ON.
+
+CC: stable@vger.kernel.org
+Signed-off-by: Jan Kara <jack@suse.cz>
+Reviewed-by: Zhang Yi <yi.zhang@huawei.com>
+Link: https://patch.msgid.link/20250206094657.20865-3-jack@suse.cz
+Signed-off-by: Theodore Ts'o <tytso@mit.edu>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/jbd2/journal.c | 1 -
+ 1 file changed, 1 deletion(-)
+
+--- a/fs/jbd2/journal.c
++++ b/fs/jbd2/journal.c
+@@ -1884,7 +1884,6 @@ int jbd2_journal_update_sb_log_tail(jour
+
+ /* Log is no longer empty */
+ write_lock(&journal->j_state_lock);
+- WARN_ON(!sb->s_sequence);
+ journal->j_flags &= ~JBD2_FLUSHED;
+ write_unlock(&journal->j_state_lock);
+
--- /dev/null
+From 87bb368d0637c466a8a77433837056f981d01991 Mon Sep 17 00:00:00 2001
+From: Kris Van Hees <kris.van.hees@oracle.com>
+Date: Fri, 7 Mar 2025 11:53:28 -0500
+Subject: kbuild: exclude .rodata.(cst|str)* when building ranges
+
+From: Kris Van Hees <kris.van.hees@oracle.com>
+
+commit 87bb368d0637c466a8a77433837056f981d01991 upstream.
+
+The .rodata.(cst|str)* sections are often resized during the final
+linking and since these sections do not cover actual symbols there is
+no need to include them in the modules.builtin.ranges data.
+
+When these sections were included in processing and resizing occurred,
+modules were reported with ranges that extended beyond their true end,
+causing subsequent symbols (in address order) to be associated with
+the wrong module.
+
+Fixes: 5f5e7344322f ("kbuild: generate offset range data for builtin modules")
+Cc: stable@vger.kernel.org
+Signed-off-by: Kris Van Hees <kris.van.hees@oracle.com>
+Reviewed-by: Jack Vogel <jack.vogel@oracle.com>
+Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ scripts/generate_builtin_ranges.awk | 5 +++++
+ 1 file changed, 5 insertions(+)
+
+diff --git a/scripts/generate_builtin_ranges.awk b/scripts/generate_builtin_ranges.awk
+index b9ec761b3bef..d4bd5c2b998c 100755
+--- a/scripts/generate_builtin_ranges.awk
++++ b/scripts/generate_builtin_ranges.awk
+@@ -282,6 +282,11 @@ ARGIND == 2 && !anchor && NF == 2 && $1 ~ /^0x/ && $2 !~ /^0x/ {
+ # section.
+ #
+ ARGIND == 2 && sect && NF == 4 && /^ [^ \*]/ && !($1 in sect_addend) {
++ # There are a few sections with constant data (without symbols) that
++ # can get resized during linking, so it is best to ignore them.
++ if ($1 ~ /^\.rodata\.(cst|str)[0-9]/)
++ next;
++
+ if (!($1 in sect_base)) {
+ sect_base[$1] = base;
+
+--
+2.49.0
+
--- /dev/null
+From 2528eec7da0ec58fcae6d12cfa79a622c933d86b Mon Sep 17 00:00:00 2001
+From: Abel Vesa <abel.vesa@linaro.org>
+Date: Wed, 5 Mar 2025 15:09:06 +0200
+Subject: leds: rgb: leds-qcom-lpg: Fix calculation of best period Hi-Res PWMs
+
+From: Abel Vesa <abel.vesa@linaro.org>
+
+commit 2528eec7da0ec58fcae6d12cfa79a622c933d86b upstream.
+
+When determining the actual best period by looping through all
+possible PWM configs, the resolution currently used is based on
+bit shift value which is off-by-one above the possible maximum
+PWM value allowed.
+
+So subtract one from the resolution before determining the best
+period so that the maximum duty cycle requested by the PWM user
+won't result in a value above the maximum allowed by the selected
+resolution.
+
+Cc: stable@vger.kernel.org # 6.4
+Fixes: b00d2ed37617 ("leds: rgb: leds-qcom-lpg: Add support for high resolution PWM")
+Signed-off-by: Abel Vesa <abel.vesa@linaro.org>
+Reviewed-by: Sebastian Reichel <sre@kernel.org>
+Link: https://lore.kernel.org/r/20250305-leds-qcom-lpg-fix-max-pwm-on-hi-res-v4-3-bfe124a53a9f@linaro.org
+Signed-off-by: Lee Jones <lee@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/leds/rgb/leds-qcom-lpg.c | 6 +++---
+ 1 file changed, 3 insertions(+), 3 deletions(-)
+
+--- a/drivers/leds/rgb/leds-qcom-lpg.c
++++ b/drivers/leds/rgb/leds-qcom-lpg.c
+@@ -461,7 +461,7 @@ static int lpg_calc_freq(struct lpg_chan
+ max_res = LPG_RESOLUTION_9BIT;
+ }
+
+- min_period = div64_u64((u64)NSEC_PER_SEC * (1 << pwm_resolution_arr[0]),
++ min_period = div64_u64((u64)NSEC_PER_SEC * ((1 << pwm_resolution_arr[0]) - 1),
+ clk_rate_arr[clk_len - 1]);
+ if (period <= min_period)
+ return -EINVAL;
+@@ -482,7 +482,7 @@ static int lpg_calc_freq(struct lpg_chan
+ */
+
+ for (i = 0; i < pwm_resolution_count; i++) {
+- resolution = 1 << pwm_resolution_arr[i];
++ resolution = (1 << pwm_resolution_arr[i]) - 1;
+ for (clk_sel = 1; clk_sel < clk_len; clk_sel++) {
+ u64 numerator = period * clk_rate_arr[clk_sel];
+
+@@ -1291,7 +1291,7 @@ static int lpg_pwm_get_state(struct pwm_
+ if (ret)
+ return ret;
+
+- state->period = DIV_ROUND_UP_ULL((u64)NSEC_PER_SEC * (1 << resolution) *
++ state->period = DIV_ROUND_UP_ULL((u64)NSEC_PER_SEC * ((1 << resolution) - 1) *
+ pre_div * (1 << m), refclk);
+ state->duty_cycle = DIV_ROUND_UP_ULL((u64)NSEC_PER_SEC * pwm_value * pre_div * (1 << m), refclk);
+ } else {
--- /dev/null
+From b7881eacc07fdf50be3f33c662997541bb59366d Mon Sep 17 00:00:00 2001
+From: Abel Vesa <abel.vesa@linaro.org>
+Date: Wed, 5 Mar 2025 15:09:05 +0200
+Subject: leds: rgb: leds-qcom-lpg: Fix pwm resolution max for Hi-Res PWMs
+
+From: Abel Vesa <abel.vesa@linaro.org>
+
+commit b7881eacc07fdf50be3f33c662997541bb59366d upstream.
+
+Ideally, the requested duty cycle should never translate to a PWM
+value higher than the selected resolution (PWM size), but currently the
+best matched period is never reported back to the PWM consumer, so the
+consumer will still be using the requested period which is higher than
+the best matched one. This will result in PWM consumer requesting
+duty cycle values higher than the allowed PWM value.
+
+For example, a consumer might request a period of 5ms while the best
+(closest) period the PWM hardware will do is 4.26ms. For this best
+matched resolution, if the selected resolution is 8-bit wide, when
+the consumer asks for a duty cycle of 5ms, the PWM value will be 300,
+which is outside of what the resolution allows. This will happen with
+all possible resolutions when selected.
+
+Since for these Hi-Res PWMs, the current implementation is capping the PWM
+value at a 15-bit resolution, even when lower resolutions are selected,
+the value will be wrapped around by the HW internal logic to the selected
+resolution.
+
+Fix the issue by capping the PWM value to the maximum value allowed by
+the selected resolution.
+
+Cc: stable@vger.kernel.org # 6.4
+Fixes: b00d2ed37617 ("leds: rgb: leds-qcom-lpg: Add support for high resolution PWM")
+Signed-off-by: Abel Vesa <abel.vesa@linaro.org>
+Reviewed-by: Bjorn Andersson <andersson@kernel.org>
+Reviewed-by: Sebastian Reichel <sre@kernel.org>
+Link: https://lore.kernel.org/r/20250305-leds-qcom-lpg-fix-max-pwm-on-hi-res-v4-2-bfe124a53a9f@linaro.org
+Signed-off-by: Lee Jones <lee@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/leds/rgb/leds-qcom-lpg.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/leds/rgb/leds-qcom-lpg.c
++++ b/drivers/leds/rgb/leds-qcom-lpg.c
+@@ -529,7 +529,7 @@ static void lpg_calc_duty(struct lpg_cha
+ unsigned int clk_rate;
+
+ if (chan->subtype == LPG_SUBTYPE_HI_RES_PWM) {
+- max = LPG_RESOLUTION_15BIT - 1;
++ max = BIT(lpg_pwm_resolution_hi_res[chan->pwm_resolution_sel]) - 1;
+ clk_rate = lpg_clk_rates_hi_res[chan->clk_sel];
+ } else {
+ max = LPG_RESOLUTION_9BIT - 1;
--- /dev/null
+From 8b46fdaea819a679da176b879e7b0674a1161a5e Mon Sep 17 00:00:00 2001
+From: T Pratham <t-pratham@ti.com>
+Date: Wed, 19 Mar 2025 16:44:38 +0530
+Subject: lib: scatterlist: fix sg_split_phys to preserve original scatterlist offsets
+
+From: T Pratham <t-pratham@ti.com>
+
+commit 8b46fdaea819a679da176b879e7b0674a1161a5e upstream.
+
+The split_sg_phys function was incorrectly setting the offsets of all
+scatterlist entries (except the first) to 0. Only the first scatterlist
+entry's offset and length needs to be modified to account for the skip.
+Setting the rest entries' offsets to 0 could lead to incorrect data
+access.
+
+I am using this function in a crypto driver that I'm currently developing
+(not yet sent to mailing list). During testing, it was observed that the
+output scatterlists (except the first one) contained incorrect garbage
+data.
+
+I narrowed this issue down to the call of sg_split(). Upon debugging
+inside this function, I found that this resetting of offset is the cause
+of the problem, causing the subsequent scatterlists to point to incorrect
+memory locations in a page. By removing this code, I am obtaining
+expected data in all the split output scatterlists. Thus, this was indeed
+causing observable runtime effects!
+
+This patch removes the offending code, ensuring that the page offsets in
+the input scatterlist are preserved in the output scatterlist.
+
+Link: https://lkml.kernel.org/r/20250319111437.1969903-1-t-pratham@ti.com
+Fixes: f8bcbe62acd0 ("lib: scatterlist: add sg splitting function")
+Signed-off-by: T Pratham <t-pratham@ti.com>
+Cc: Robert Jarzmik <robert.jarzmik@free.fr>
+Cc: Jens Axboe <axboe@kernel.dk>
+Cc: Kamlesh Gurudasani <kamlesh@ti.com>
+Cc: Praneeth Bajjuri <praneeth@ti.com>
+Cc: Vignesh Raghavendra <vigneshr@ti.com>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ lib/sg_split.c | 2 --
+ 1 file changed, 2 deletions(-)
+
+--- a/lib/sg_split.c
++++ b/lib/sg_split.c
+@@ -88,8 +88,6 @@ static void sg_split_phys(struct sg_spli
+ if (!j) {
+ out_sg->offset += split->skip_sg0;
+ out_sg->length -= split->skip_sg0;
+- } else {
+- out_sg->offset = 0;
+ }
+ sg_dma_address(out_sg) = 0;
+ sg_dma_len(out_sg) = 0;
--- /dev/null
+From 495f53d5cca0f939eaed9dca90b67e7e6fb0e30c Mon Sep 17 00:00:00 2001
+From: Boqun Feng <boqun.feng@gmail.com>
+Date: Wed, 26 Mar 2025 11:08:30 -0700
+Subject: locking/lockdep: Decrease nr_unused_locks if lock unused in zap_class()
+
+From: Boqun Feng <boqun.feng@gmail.com>
+
+commit 495f53d5cca0f939eaed9dca90b67e7e6fb0e30c upstream.
+
+Currently, when a lock class is allocated, nr_unused_locks will be
+increased by 1, until it gets used: nr_unused_locks will be decreased by
+1 in mark_lock(). However, one scenario is missed: a lock class may be
+zapped without even being used once. This could result into a situation
+that nr_unused_locks != 0 but no unused lock class is active in the
+system, and when `cat /proc/lockdep_stats`, a WARN_ON() will
+be triggered in a CONFIG_DEBUG_LOCKDEP=y kernel:
+
+ [...] DEBUG_LOCKS_WARN_ON(debug_atomic_read(nr_unused_locks) != nr_unused)
+ [...] WARNING: CPU: 41 PID: 1121 at kernel/locking/lockdep_proc.c:283 lockdep_stats_show+0xba9/0xbd0
+
+And as a result, lockdep will be disabled after this.
+
+Therefore, nr_unused_locks needs to be accounted correctly at
+zap_class() time.
+
+Signed-off-by: Boqun Feng <boqun.feng@gmail.com>
+Signed-off-by: Ingo Molnar <mingo@kernel.org>
+Reviewed-by: Waiman Long <longman@redhat.com>
+Cc: stable@vger.kernel.org
+Link: https://lore.kernel.org/r/20250326180831.510348-1-boqun.feng@gmail.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ kernel/locking/lockdep.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/kernel/locking/lockdep.c
++++ b/kernel/locking/lockdep.c
+@@ -6223,6 +6223,9 @@ static void zap_class(struct pending_fre
+ hlist_del_rcu(&class->hash_entry);
+ WRITE_ONCE(class->key, NULL);
+ WRITE_ONCE(class->name, NULL);
++ /* Class allocated but not used, -1 in nr_unused_locks */
++ if (class->usage_mask == 0)
++ debug_atomic_dec(nr_unused_locks);
+ nr_lock_classes--;
+ __clear_bit(class - lock_classes, lock_classes_in_use);
+ if (class - lock_classes == max_lock_class_idx)
--- /dev/null
+From bf0c9fb462038815f5f502653fb6dba06e6af415 Mon Sep 17 00:00:00 2001
+From: Kartik Rajput <kkartik@nvidia.com>
+Date: Thu, 23 Jan 2025 18:16:32 +0530
+Subject: mailbox: tegra-hsp: Define dimensioning masks in SoC data
+
+From: Kartik Rajput <kkartik@nvidia.com>
+
+commit bf0c9fb462038815f5f502653fb6dba06e6af415 upstream.
+
+Tegra264 has updated HSP_INT_DIMENSIONING register as follows:
+ * nSI is now BIT17:BIT21.
+ * nDB is now BIT12:BIT16.
+
+Currently, we are using a static macro HSP_nINT_MASK to get the values
+from HSP_INT_DIMENSIONING register. This results in wrong values for nSI
+for HSP instances that supports 16 shared interrupts.
+
+Define dimensioning masks in soc data and use them to parse nSI, nDB,
+nAS, nSS & nSM values.
+
+Fixes: 602dbbacc3ef ("mailbox: tegra: add support for Tegra264")
+Cc: stable@vger.kernel.org
+Signed-off-by: Kartik Rajput <kkartik@nvidia.com>
+Acked-by: Thierry Reding <treding@nvidia.com>
+Acked-by: Jon Hunter <jonathanh@nvidia.com>
+Signed-off-by: Jassi Brar <jassisinghbrar@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/mailbox/tegra-hsp.c | 72 ++++++++++++++++++++++++++++++++++++--------
+ 1 file changed, 60 insertions(+), 12 deletions(-)
+
+--- a/drivers/mailbox/tegra-hsp.c
++++ b/drivers/mailbox/tegra-hsp.c
+@@ -1,6 +1,6 @@
+ // SPDX-License-Identifier: GPL-2.0-only
+ /*
+- * Copyright (c) 2016-2023, NVIDIA CORPORATION. All rights reserved.
++ * Copyright (c) 2016-2025, NVIDIA CORPORATION. All rights reserved.
+ */
+
+ #include <linux/delay.h>
+@@ -28,12 +28,6 @@
+ #define HSP_INT_FULL_MASK 0xff
+
+ #define HSP_INT_DIMENSIONING 0x380
+-#define HSP_nSM_SHIFT 0
+-#define HSP_nSS_SHIFT 4
+-#define HSP_nAS_SHIFT 8
+-#define HSP_nDB_SHIFT 12
+-#define HSP_nSI_SHIFT 16
+-#define HSP_nINT_MASK 0xf
+
+ #define HSP_DB_TRIGGER 0x0
+ #define HSP_DB_ENABLE 0x4
+@@ -97,6 +91,20 @@ struct tegra_hsp_soc {
+ bool has_per_mb_ie;
+ bool has_128_bit_mb;
+ unsigned int reg_stride;
++
++ /* Shifts for dimensioning register. */
++ unsigned int si_shift;
++ unsigned int db_shift;
++ unsigned int as_shift;
++ unsigned int ss_shift;
++ unsigned int sm_shift;
++
++ /* Masks for dimensioning register. */
++ unsigned int si_mask;
++ unsigned int db_mask;
++ unsigned int as_mask;
++ unsigned int ss_mask;
++ unsigned int sm_mask;
+ };
+
+ struct tegra_hsp {
+@@ -747,11 +755,11 @@ static int tegra_hsp_probe(struct platfo
+ return PTR_ERR(hsp->regs);
+
+ value = tegra_hsp_readl(hsp, HSP_INT_DIMENSIONING);
+- hsp->num_sm = (value >> HSP_nSM_SHIFT) & HSP_nINT_MASK;
+- hsp->num_ss = (value >> HSP_nSS_SHIFT) & HSP_nINT_MASK;
+- hsp->num_as = (value >> HSP_nAS_SHIFT) & HSP_nINT_MASK;
+- hsp->num_db = (value >> HSP_nDB_SHIFT) & HSP_nINT_MASK;
+- hsp->num_si = (value >> HSP_nSI_SHIFT) & HSP_nINT_MASK;
++ hsp->num_sm = (value >> hsp->soc->sm_shift) & hsp->soc->sm_mask;
++ hsp->num_ss = (value >> hsp->soc->ss_shift) & hsp->soc->ss_mask;
++ hsp->num_as = (value >> hsp->soc->as_shift) & hsp->soc->as_mask;
++ hsp->num_db = (value >> hsp->soc->db_shift) & hsp->soc->db_mask;
++ hsp->num_si = (value >> hsp->soc->si_shift) & hsp->soc->si_mask;
+
+ err = platform_get_irq_byname_optional(pdev, "doorbell");
+ if (err >= 0)
+@@ -915,6 +923,16 @@ static const struct tegra_hsp_soc tegra1
+ .has_per_mb_ie = false,
+ .has_128_bit_mb = false,
+ .reg_stride = 0x100,
++ .si_shift = 16,
++ .db_shift = 12,
++ .as_shift = 8,
++ .ss_shift = 4,
++ .sm_shift = 0,
++ .si_mask = 0xf,
++ .db_mask = 0xf,
++ .as_mask = 0xf,
++ .ss_mask = 0xf,
++ .sm_mask = 0xf,
+ };
+
+ static const struct tegra_hsp_soc tegra194_hsp_soc = {
+@@ -922,6 +940,16 @@ static const struct tegra_hsp_soc tegra1
+ .has_per_mb_ie = true,
+ .has_128_bit_mb = false,
+ .reg_stride = 0x100,
++ .si_shift = 16,
++ .db_shift = 12,
++ .as_shift = 8,
++ .ss_shift = 4,
++ .sm_shift = 0,
++ .si_mask = 0xf,
++ .db_mask = 0xf,
++ .as_mask = 0xf,
++ .ss_mask = 0xf,
++ .sm_mask = 0xf,
+ };
+
+ static const struct tegra_hsp_soc tegra234_hsp_soc = {
+@@ -929,6 +957,16 @@ static const struct tegra_hsp_soc tegra2
+ .has_per_mb_ie = false,
+ .has_128_bit_mb = true,
+ .reg_stride = 0x100,
++ .si_shift = 16,
++ .db_shift = 12,
++ .as_shift = 8,
++ .ss_shift = 4,
++ .sm_shift = 0,
++ .si_mask = 0xf,
++ .db_mask = 0xf,
++ .as_mask = 0xf,
++ .ss_mask = 0xf,
++ .sm_mask = 0xf,
+ };
+
+ static const struct tegra_hsp_soc tegra264_hsp_soc = {
+@@ -936,6 +974,16 @@ static const struct tegra_hsp_soc tegra2
+ .has_per_mb_ie = false,
+ .has_128_bit_mb = true,
+ .reg_stride = 0x1000,
++ .si_shift = 17,
++ .db_shift = 12,
++ .as_shift = 8,
++ .ss_shift = 4,
++ .sm_shift = 0,
++ .si_mask = 0x1f,
++ .db_mask = 0x1f,
++ .as_mask = 0xf,
++ .ss_mask = 0xf,
++ .sm_mask = 0xf,
+ };
+
+ static const struct of_device_id tegra_hsp_match[] = {
--- /dev/null
+From 4cdf1d2a816a93fa02f7b6b5492dc7f55af2a199 Mon Sep 17 00:00:00 2001
+From: Chenyuan Yang <chenyuan0y@gmail.com>
+Date: Mon, 24 Feb 2025 17:37:36 -0600
+Subject: mfd: ene-kb3930: Fix a potential NULL pointer dereference
+
+From: Chenyuan Yang <chenyuan0y@gmail.com>
+
+commit 4cdf1d2a816a93fa02f7b6b5492dc7f55af2a199 upstream.
+
+The off_gpios could be NULL. Add missing check in the kb3930_probe().
+This is similar to the issue fixed in commit b1ba8bcb2d1f
+("backlight: hx8357: Fix potential NULL pointer dereference").
+
+This was detected by our static analysis tool.
+
+Cc: stable@vger.kernel.org
+Fixes: ede6b2d1dfc0 ("mfd: ene-kb3930: Add driver for ENE KB3930 Embedded Controller")
+Suggested-by: Lee Jones <lee@kernel.org>
+Signed-off-by: Chenyuan Yang <chenyuan0y@gmail.com>
+Link: https://lore.kernel.org/r/20250224233736.1919739-1-chenyuan0y@gmail.com
+Signed-off-by: Lee Jones <lee@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/mfd/ene-kb3930.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/mfd/ene-kb3930.c
++++ b/drivers/mfd/ene-kb3930.c
+@@ -162,7 +162,7 @@ static int kb3930_probe(struct i2c_clien
+ devm_gpiod_get_array_optional(dev, "off", GPIOD_IN);
+ if (IS_ERR(ddata->off_gpios))
+ return PTR_ERR(ddata->off_gpios);
+- if (ddata->off_gpios->ndescs < 2) {
++ if (ddata->off_gpios && ddata->off_gpios->ndescs < 2) {
+ dev_err(dev, "invalid off-gpios property\n");
+ return -EINVAL;
+ }
--- /dev/null
+From 443041deb5ef6a1289a99ed95015ec7442f141dc Mon Sep 17 00:00:00 2001
+From: Gang Yan <yangang@kylinos.cn>
+Date: Fri, 28 Mar 2025 15:27:16 +0100
+Subject: mptcp: fix NULL pointer in can_accept_new_subflow
+
+From: Gang Yan <yangang@kylinos.cn>
+
+commit 443041deb5ef6a1289a99ed95015ec7442f141dc upstream.
+
+When testing valkey benchmark tool with MPTCP, the kernel panics in
+'mptcp_can_accept_new_subflow' because subflow_req->msk is NULL.
+
+Call trace:
+
+ mptcp_can_accept_new_subflow (./net/mptcp/subflow.c:63 (discriminator 4)) (P)
+ subflow_syn_recv_sock (./net/mptcp/subflow.c:854)
+ tcp_check_req (./net/ipv4/tcp_minisocks.c:863)
+ tcp_v4_rcv (./net/ipv4/tcp_ipv4.c:2268)
+ ip_protocol_deliver_rcu (./net/ipv4/ip_input.c:207)
+ ip_local_deliver_finish (./net/ipv4/ip_input.c:234)
+ ip_local_deliver (./net/ipv4/ip_input.c:254)
+ ip_rcv_finish (./net/ipv4/ip_input.c:449)
+ ...
+
+According to the debug log, the same req received two SYN-ACK in a very
+short time, very likely because the client retransmits the syn ack due
+to multiple reasons.
+
+Even if the packets are transmitted with a relevant time interval, they
+can be processed by the server on different CPUs concurrently). The
+'subflow_req->msk' ownership is transferred to the subflow the first,
+and there will be a risk of a null pointer dereference here.
+
+This patch fixes this issue by moving the 'subflow_req->msk' under the
+`own_req == true` conditional.
+
+Note that the !msk check in subflow_hmac_valid() can be dropped, because
+the same check already exists under the own_req mpj branch where the
+code has been moved to.
+
+Fixes: 9466a1ccebbe ("mptcp: enable JOIN requests even if cookies are in use")
+Cc: stable@vger.kernel.org
+Suggested-by: Paolo Abeni <pabeni@redhat.com>
+Signed-off-by: Gang Yan <yangang@kylinos.cn>
+Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
+Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
+Link: https://patch.msgid.link/20250328-net-mptcp-misc-fixes-6-15-v1-1-34161a482a7f@kernel.org
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/mptcp/subflow.c | 15 ++++++++-------
+ 1 file changed, 8 insertions(+), 7 deletions(-)
+
+--- a/net/mptcp/subflow.c
++++ b/net/mptcp/subflow.c
+@@ -754,8 +754,6 @@ static bool subflow_hmac_valid(const str
+
+ subflow_req = mptcp_subflow_rsk(req);
+ msk = subflow_req->msk;
+- if (!msk)
+- return false;
+
+ subflow_generate_hmac(READ_ONCE(msk->remote_key),
+ READ_ONCE(msk->local_key),
+@@ -853,12 +851,8 @@ static struct sock *subflow_syn_recv_soc
+
+ } else if (subflow_req->mp_join) {
+ mptcp_get_options(skb, &mp_opt);
+- if (!(mp_opt.suboptions & OPTION_MPTCP_MPJ_ACK) ||
+- !subflow_hmac_valid(req, &mp_opt) ||
+- !mptcp_can_accept_new_subflow(subflow_req->msk)) {
+- SUBFLOW_REQ_INC_STATS(req, MPTCP_MIB_JOINACKMAC);
++ if (!(mp_opt.suboptions & OPTION_MPTCP_MPJ_ACK))
+ fallback = true;
+- }
+ }
+
+ create_child:
+@@ -907,6 +901,13 @@ create_child:
+ subflow_add_reset_reason(skb, MPTCP_RST_EPROHIBIT);
+ goto dispose_child;
+ }
++
++ if (!subflow_hmac_valid(req, &mp_opt) ||
++ !mptcp_can_accept_new_subflow(subflow_req->msk)) {
++ SUBFLOW_REQ_INC_STATS(req, MPTCP_MIB_JOINACKMAC);
++ subflow_add_reset_reason(skb, MPTCP_RST_EPROHIBIT);
++ goto dispose_child;
++ }
+
+ /* move the msk reference ownership to the subflow */
+ subflow_req->msk = NULL;
--- /dev/null
+From 21c02e8272bc95ba0dd44943665c669029b42760 Mon Sep 17 00:00:00 2001
+From: "Matthieu Baerts (NGI0)" <matttbe@kernel.org>
+Date: Mon, 7 Apr 2025 20:26:32 +0200
+Subject: mptcp: only inc MPJoinAckHMacFailure for HMAC failures
+
+From: Matthieu Baerts (NGI0) <matttbe@kernel.org>
+
+commit 21c02e8272bc95ba0dd44943665c669029b42760 upstream.
+
+Recently, during a debugging session using local MPTCP connections, I
+noticed MPJoinAckHMacFailure was not zero on the server side. The
+counter was in fact incremented when the PM rejected new subflows,
+because the 'subflow' limit was reached.
+
+The fix is easy, simply dissociating the two cases: only the HMAC
+validation check should increase MPTCP_MIB_JOINACKMAC counter.
+
+Fixes: 4cf8b7e48a09 ("subflow: introduce and use mptcp_can_accept_new_subflow()")
+Cc: stable@vger.kernel.org
+Reviewed-by: Geliang Tang <geliang@kernel.org>
+Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
+Reviewed-by: Simon Horman <horms@kernel.org>
+Link: https://patch.msgid.link/20250407-net-mptcp-hmac-failure-mib-v1-1-3c9ecd0a3a50@kernel.org
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/mptcp/subflow.c | 8 ++++++--
+ 1 file changed, 6 insertions(+), 2 deletions(-)
+
+--- a/net/mptcp/subflow.c
++++ b/net/mptcp/subflow.c
+@@ -902,12 +902,16 @@ create_child:
+ goto dispose_child;
+ }
+
+- if (!subflow_hmac_valid(req, &mp_opt) ||
+- !mptcp_can_accept_new_subflow(subflow_req->msk)) {
++ if (!subflow_hmac_valid(req, &mp_opt)) {
+ SUBFLOW_REQ_INC_STATS(req, MPTCP_MIB_JOINACKMAC);
+ subflow_add_reset_reason(skb, MPTCP_RST_EPROHIBIT);
+ goto dispose_child;
+ }
++
++ if (!mptcp_can_accept_new_subflow(owner)) {
++ subflow_add_reset_reason(skb, MPTCP_RST_EPROHIBIT);
++ goto dispose_child;
++ }
+
+ /* move the msk reference ownership to the subflow */
+ subflow_req->msk = NULL;
--- /dev/null
+From d027951dc85cb2e15924c980dc22a6754d100c7c Mon Sep 17 00:00:00 2001
+From: Wentao Liang <vulab@iscas.ac.cn>
+Date: Wed, 2 Apr 2025 11:16:43 +0800
+Subject: mtd: inftlcore: Add error check for inftl_read_oob()
+
+From: Wentao Liang <vulab@iscas.ac.cn>
+
+commit d027951dc85cb2e15924c980dc22a6754d100c7c upstream.
+
+In INFTL_findwriteunit(), the return value of inftl_read_oob()
+need to be checked. A proper implementation can be
+found in INFTL_deleteblock(). The status will be set as
+SECTOR_IGNORE to break from the while-loop correctly
+if the inftl_read_oob() fails.
+
+Fixes: 8593fbc68b0d ("[MTD] Rework the out of band handling completely")
+Cc: stable@vger.kernel.org # v2.6+
+Signed-off-by: Wentao Liang <vulab@iscas.ac.cn>
+Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/mtd/inftlcore.c | 9 +++++----
+ 1 file changed, 5 insertions(+), 4 deletions(-)
+
+--- a/drivers/mtd/inftlcore.c
++++ b/drivers/mtd/inftlcore.c
+@@ -482,10 +482,11 @@ static inline u16 INFTL_findwriteunit(st
+ silly = MAX_LOOPS;
+
+ while (thisEUN <= inftl->lastEUN) {
+- inftl_read_oob(mtd, (thisEUN * inftl->EraseSize) +
+- blockofs, 8, &retlen, (char *)&bci);
+-
+- status = bci.Status | bci.Status1;
++ if (inftl_read_oob(mtd, (thisEUN * inftl->EraseSize) +
++ blockofs, 8, &retlen, (char *)&bci) < 0)
++ status = SECTOR_IGNORE;
++ else
++ status = bci.Status | bci.Status1;
+ pr_debug("INFTL: status of block %d in EUN %d is %x\n",
+ block , writeEUN, status);
+
--- /dev/null
+From b79fe1829975556854665258cf4d2476784a89db Mon Sep 17 00:00:00 2001
+From: Wentao Liang <vulab@iscas.ac.cn>
+Date: Wed, 2 Apr 2025 15:56:23 +0800
+Subject: mtd: rawnand: Add status chack in r852_ready()
+
+From: Wentao Liang <vulab@iscas.ac.cn>
+
+commit b79fe1829975556854665258cf4d2476784a89db upstream.
+
+In r852_ready(), the dev get from r852_get_dev() need to be checked.
+An unstable device should not be ready. A proper implementation can
+be found in r852_read_byte(). Add a status check and return 0 when it is
+unstable.
+
+Fixes: 50a487e7719c ("mtd: rawnand: Pass a nand_chip object to chip->dev_ready()")
+Cc: stable@vger.kernel.org # v4.20+
+Signed-off-by: Wentao Liang <vulab@iscas.ac.cn>
+Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/mtd/nand/raw/r852.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/drivers/mtd/nand/raw/r852.c
++++ b/drivers/mtd/nand/raw/r852.c
+@@ -387,6 +387,9 @@ static int r852_wait(struct nand_chip *c
+ static int r852_ready(struct nand_chip *chip)
+ {
+ struct r852_device *dev = r852_get_dev(nand_to_mtd(chip));
++ if (dev->card_unstable)
++ return 0;
++
+ return !(r852_read_reg(dev, R852_CARD_STA) & R852_CARD_STA_BUSY);
+ }
+
svcrdma-do-not-unregister-device-for-listeners.patch
soc-samsung-exynos-chipid-add-null-pointer-check-in-exynos_chipid_probe.patch
smb311-client-fix-missing-tcon-check-when-mounting-with-linux-posix-extensions.patch
+ima-limit-the-number-of-open-writers-integrity-violations.patch
+ima-limit-the-number-of-tomtou-integrity-violations.patch
+i3c-master-svc-use-readsb-helper-for-reading-mdb.patch
+i3c-add-null-pointer-check-in-i3c_master_queue_ibi.patch
+jbd2-remove-wrong-sb-s_sequence-check.patch
+kbuild-exclude-.rodata.-cst-str-when-building-ranges.patch
+leds-rgb-leds-qcom-lpg-fix-pwm-resolution-max-for-hi-res-pwms.patch
+leds-rgb-leds-qcom-lpg-fix-calculation-of-best-period-hi-res-pwms.patch
+mfd-ene-kb3930-fix-a-potential-null-pointer-dereference.patch
+mailbox-tegra-hsp-define-dimensioning-masks-in-soc-data.patch
+locking-lockdep-decrease-nr_unused_locks-if-lock-unused-in-zap_class.patch
+lib-scatterlist-fix-sg_split_phys-to-preserve-original-scatterlist-offsets.patch
+mptcp-fix-null-pointer-in-can_accept_new_subflow.patch
+mptcp-only-inc-mpjoinackhmacfailure-for-hmac-failures.patch
+mtd-inftlcore-add-error-check-for-inftl_read_oob.patch
+mtd-rawnand-add-status-chack-in-r852_ready.patch
+arm64-mops-do-not-dereference-src-reg-for-a-set-operation.patch
+arm64-tegra-remove-the-orin-nx-nano-suspend-key.patch
+arm64-mm-correct-the-update-of-max_pfn.patch
+arm64-dts-mediatek-mt8173-fix-disp-pwm-compatible-string.patch
+arm64-dts-exynos-gs101-disable-pinctrl_gsacore-node.patch
+backlight-led_bl-hold-led_access-lock-when-calling-led_sysfs_disable.patch
projects / thirdparty / kernel / stable-queue.git / commitdiff
