]> git.ipfire.org Git - thirdparty/kernel/stable-queue.git/commitdiff
6.6-stable patches
authorGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Mon, 1 Dec 2025 16:07:49 +0000 (17:07 +0100)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Mon, 1 Dec 2025 16:07:49 +0000 (17:07 +0100)
added patches:
alsa-usb-audio-add-dsd-quirk-for-leak-stereo-230.patch
arm-dts-nxp-imx6ul-correct-sai3-interrupt-line.patch
atm-fore200e-fix-possible-data-race-in-fore200e_open.patch
can-sja1000-fix-max-irq-loop-handling.patch
can-sun4i_can-sun4i_can_interrupt-fix-max-irq-loop-handling.patch
ceph-fix-crash-in-process_v2_sparse_read-for-encrypted-directories.patch
dm-verity-fix-unreliable-memory-allocation.patch
drivers-usb-dwc3-fix-pci-parent-check.patch
firmware-stratix10-svc-fix-bug-in-saving-controller-data.patch
mptcp-clear-scheduled-subflows-on-retransmit.patch
serial-amba-pl011-prefer-dma_mapping_error-over-explicit-address-checking.patch
slimbus-ngd-fix-reference-count-leak-in-qcom_slim_ngd_notify_slaves.patch
smb-client-fix-memory-leak-in-cifs_construct_tcon.patch
thunderbolt-add-support-for-intel-wildcat-lake.patch

15 files changed:
queue-6.6/alsa-usb-audio-add-dsd-quirk-for-leak-stereo-230.patch [new file with mode: 0644]
queue-6.6/arm-dts-nxp-imx6ul-correct-sai3-interrupt-line.patch [new file with mode: 0644]
queue-6.6/atm-fore200e-fix-possible-data-race-in-fore200e_open.patch [new file with mode: 0644]
queue-6.6/can-sja1000-fix-max-irq-loop-handling.patch [new file with mode: 0644]
queue-6.6/can-sun4i_can-sun4i_can_interrupt-fix-max-irq-loop-handling.patch [new file with mode: 0644]
queue-6.6/ceph-fix-crash-in-process_v2_sparse_read-for-encrypted-directories.patch [new file with mode: 0644]
queue-6.6/dm-verity-fix-unreliable-memory-allocation.patch [new file with mode: 0644]
queue-6.6/drivers-usb-dwc3-fix-pci-parent-check.patch [new file with mode: 0644]
queue-6.6/firmware-stratix10-svc-fix-bug-in-saving-controller-data.patch [new file with mode: 0644]
queue-6.6/mptcp-clear-scheduled-subflows-on-retransmit.patch [new file with mode: 0644]
queue-6.6/serial-amba-pl011-prefer-dma_mapping_error-over-explicit-address-checking.patch [new file with mode: 0644]
queue-6.6/series
queue-6.6/slimbus-ngd-fix-reference-count-leak-in-qcom_slim_ngd_notify_slaves.patch [new file with mode: 0644]
queue-6.6/smb-client-fix-memory-leak-in-cifs_construct_tcon.patch [new file with mode: 0644]
queue-6.6/thunderbolt-add-support-for-intel-wildcat-lake.patch [new file with mode: 0644]

diff --git a/queue-6.6/alsa-usb-audio-add-dsd-quirk-for-leak-stereo-230.patch b/queue-6.6/alsa-usb-audio-add-dsd-quirk-for-leak-stereo-230.patch
new file mode 100644 (file)
index 0000000..22d13d2
--- /dev/null
@@ -0,0 +1,46 @@
+From c83fc13960643c4429cd9dfef1321e6430a81b47 Mon Sep 17 00:00:00 2001
+From: Ivan Zhaldak <i.v.zhaldak@gmail.com>
+Date: Mon, 17 Nov 2025 15:58:35 +0300
+Subject: ALSA: usb-audio: Add DSD quirk for LEAK Stereo 230
+
+From: Ivan Zhaldak <i.v.zhaldak@gmail.com>
+
+commit c83fc13960643c4429cd9dfef1321e6430a81b47 upstream.
+
+Integrated amplifier LEAK Stereo 230 by IAG Limited has built-in
+ESS9038Q2M DAC served by XMOS controller. It supports both DSD Native
+and DSD-over-PCM (DoP) operational modes. But it doesn't work properly
+by default and tries DSD-to-PCM conversion. USB quirks below allow it
+to operate as designed.
+
+Add DSD_RAW quirk flag for IAG Limited devices (vendor ID 0x2622)
+Add DSD format quirk for LEAK Stereo 230 (USB ID 0x2622:0x0061)
+
+Signed-off-by: Ivan Zhaldak <i.v.zhaldak@gmail.com>
+Cc: <stable@vger.kernel.org>
+Link: https://patch.msgid.link/20251117125848.30769-1-i.v.zhaldak@gmail.com
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ sound/usb/quirks.c |    3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/sound/usb/quirks.c
++++ b/sound/usb/quirks.c
+@@ -1928,6 +1928,7 @@ u64 snd_usb_interface_dsd_format_quirks(
+       case USB_ID(0x249c, 0x9326): /* M2Tech Young MkIII */
+       case USB_ID(0x2616, 0x0106): /* PS Audio NuWave DAC */
+       case USB_ID(0x2622, 0x0041): /* Audiolab M-DAC+ */
++      case USB_ID(0x2622, 0x0061): /* LEAK Stereo 230 */
+       case USB_ID(0x278b, 0x5100): /* Rotel RC-1590 */
+       case USB_ID(0x27f7, 0x3002): /* W4S DAC-2v2SE */
+       case USB_ID(0x29a2, 0x0086): /* Mutec MC3+ USB */
+@@ -2311,6 +2312,8 @@ static const struct usb_audio_quirk_flag
+                  QUIRK_FLAG_DSD_RAW),
+       VENDOR_FLG(0x25ce, /* Mytek devices */
+                  QUIRK_FLAG_DSD_RAW),
++      VENDOR_FLG(0x2622, /* IAG Limited devices */
++                 QUIRK_FLAG_DSD_RAW),
+       VENDOR_FLG(0x278b, /* Rotel? */
+                  QUIRK_FLAG_DSD_RAW),
+       VENDOR_FLG(0x292b, /* Gustard/Ess based devices */
diff --git a/queue-6.6/arm-dts-nxp-imx6ul-correct-sai3-interrupt-line.patch b/queue-6.6/arm-dts-nxp-imx6ul-correct-sai3-interrupt-line.patch
new file mode 100644 (file)
index 0000000..60ebbb9
--- /dev/null
@@ -0,0 +1,36 @@
+From 1b03346314b791ad966d3c6d59253328226a2b2d Mon Sep 17 00:00:00 2001
+From: Maarten Zanders <maarten@zanders.be>
+Date: Fri, 24 Oct 2025 16:21:06 +0200
+Subject: ARM: dts: nxp: imx6ul: correct SAI3 interrupt line
+
+From: Maarten Zanders <maarten@zanders.be>
+
+commit 1b03346314b791ad966d3c6d59253328226a2b2d upstream.
+
+The i.MX6UL reference manual lists two possible interrupt lines for
+SAI3 (56 and 57, offset +32). The current device tree entry uses
+the first one (24), which prevents IRQs from being handled properly.
+
+Use the second interrupt line (25), which does allow interrupts
+to work as expected.
+
+Fixes: 36e2edf6ac07 ("ARM: dts: imx6ul: add sai support")
+Signed-off-by: Maarten Zanders <maarten@zanders.be>
+Cc: stable@vger.kernel.org
+Signed-off-by: Shawn Guo <shawnguo@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/arm/boot/dts/nxp/imx/imx6ul.dtsi |    2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/arch/arm/boot/dts/nxp/imx/imx6ul.dtsi
++++ b/arch/arm/boot/dts/nxp/imx/imx6ul.dtsi
+@@ -333,7 +333,7 @@
+                                       #sound-dai-cells = <0>;
+                                       compatible = "fsl,imx6ul-sai", "fsl,imx6sx-sai";
+                                       reg = <0x02030000 0x4000>;
+-                                      interrupts = <GIC_SPI 24 IRQ_TYPE_LEVEL_HIGH>;
++                                      interrupts = <GIC_SPI 25 IRQ_TYPE_LEVEL_HIGH>;
+                                       clocks = <&clks IMX6UL_CLK_SAI3_IPG>,
+                                                <&clks IMX6UL_CLK_SAI3>,
+                                                <&clks IMX6UL_CLK_DUMMY>, <&clks IMX6UL_CLK_DUMMY>;
diff --git a/queue-6.6/atm-fore200e-fix-possible-data-race-in-fore200e_open.patch b/queue-6.6/atm-fore200e-fix-possible-data-race-in-fore200e_open.patch
new file mode 100644 (file)
index 0000000..296cd60
--- /dev/null
@@ -0,0 +1,57 @@
+From 82fca3d8a4a34667f01ec2351a607135249c9cff Mon Sep 17 00:00:00 2001
+From: Gui-Dong Han <hanguidong02@gmail.com>
+Date: Thu, 20 Nov 2025 20:06:57 +0800
+Subject: atm/fore200e: Fix possible data race in fore200e_open()
+
+From: Gui-Dong Han <hanguidong02@gmail.com>
+
+commit 82fca3d8a4a34667f01ec2351a607135249c9cff upstream.
+
+Protect access to fore200e->available_cell_rate with rate_mtx lock in the
+error handling path of fore200e_open() to prevent a data race.
+
+The field fore200e->available_cell_rate is a shared resource used to track
+available bandwidth. It is concurrently accessed by fore200e_open(),
+fore200e_close(), and fore200e_change_qos().
+
+In fore200e_open(), the lock rate_mtx is correctly held when subtracting
+vcc->qos.txtp.max_pcr from available_cell_rate to reserve bandwidth.
+However, if the subsequent call to fore200e_activate_vcin() fails, the
+function restores the reserved bandwidth by adding back to
+available_cell_rate without holding the lock.
+
+This introduces a race condition because available_cell_rate is a global
+device resource shared across all VCCs. If the error path in
+fore200e_open() executes concurrently with operations like
+fore200e_close() or fore200e_change_qos() on other VCCs, a
+read-modify-write race occurs.
+
+Specifically, the error path reads the rate without the lock. If another
+CPU acquires the lock and modifies the rate (e.g., releasing bandwidth in
+fore200e_close()) between this read and the subsequent write, the error
+path will overwrite the concurrent update with a stale value. This results
+in incorrect bandwidth accounting.
+
+Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
+Cc: stable@vger.kernel.org
+Signed-off-by: Gui-Dong Han <hanguidong02@gmail.com>
+Reviewed-by: Simon Horman <horms@kernel.org>
+Link: https://patch.msgid.link/20251120120657.2462194-1-hanguidong02@gmail.com
+Signed-off-by: Paolo Abeni <pabeni@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/atm/fore200e.c |    2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/drivers/atm/fore200e.c
++++ b/drivers/atm/fore200e.c
+@@ -1377,7 +1377,9 @@ fore200e_open(struct atm_vcc *vcc)
+       vcc->dev_data = NULL;
++      mutex_lock(&fore200e->rate_mtx);
+       fore200e->available_cell_rate += vcc->qos.txtp.max_pcr;
++      mutex_unlock(&fore200e->rate_mtx);
+       kfree(fore200e_vcc);
+       return -EINVAL;
diff --git a/queue-6.6/can-sja1000-fix-max-irq-loop-handling.patch b/queue-6.6/can-sja1000-fix-max-irq-loop-handling.patch
new file mode 100644 (file)
index 0000000..e80ba9a
--- /dev/null
@@ -0,0 +1,45 @@
+From 30db4451c7f6aabcada029b15859a76962ec0cf8 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Thomas=20M=C3=BChlbacher?= <tmuehlbacher@posteo.net>
+Date: Sat, 15 Nov 2025 15:34:56 +0000
+Subject: can: sja1000: fix max irq loop handling
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Thomas Mühlbacher <tmuehlbacher@posteo.net>
+
+commit 30db4451c7f6aabcada029b15859a76962ec0cf8 upstream.
+
+Reading the interrupt register `SJA1000_IR` causes all of its bits to be
+reset. If we ever reach the condition of handling more than
+`SJA1000_MAX_IRQ` IRQs, we will have read the register and reset all its
+bits but without actually handling the interrupt inside of the loop
+body.
+
+This may, among other issues, cause us to never `netif_wake_queue()`
+again after a transmission interrupt.
+
+Fixes: 429da1cc841b ("can: Driver for the SJA1000 CAN controller")
+Cc: stable@vger.kernel.org
+Signed-off-by: Thomas Mühlbacher <tmuehlbacher@posteo.net>
+Acked-by: Oliver Hartkopp <socketcan@hartkopp.net>
+Link: https://patch.msgid.link/20251115153437.11419-1-tmuehlbacher@posteo.net
+Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/can/sja1000/sja1000.c |    4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/drivers/net/can/sja1000/sja1000.c
++++ b/drivers/net/can/sja1000/sja1000.c
+@@ -548,8 +548,8 @@ irqreturn_t sja1000_interrupt(int irq, v
+       if (priv->read_reg(priv, SJA1000_IER) == IRQ_OFF)
+               goto out;
+-      while ((isrc = priv->read_reg(priv, SJA1000_IR)) &&
+-             (n < SJA1000_MAX_IRQ)) {
++      while ((n < SJA1000_MAX_IRQ) &&
++             (isrc = priv->read_reg(priv, SJA1000_IR))) {
+               status = priv->read_reg(priv, SJA1000_SR);
+               /* check for absent controller due to hw unplug */
diff --git a/queue-6.6/can-sun4i_can-sun4i_can_interrupt-fix-max-irq-loop-handling.patch b/queue-6.6/can-sun4i_can-sun4i_can_interrupt-fix-max-irq-loop-handling.patch
new file mode 100644 (file)
index 0000000..7727196
--- /dev/null
@@ -0,0 +1,45 @@
+From 76544beea7cfe5bcce6d60f53811657b88ec8be1 Mon Sep 17 00:00:00 2001
+From: Marc Kleine-Budde <mkl@pengutronix.de>
+Date: Sun, 16 Nov 2025 16:55:26 +0100
+Subject: can: sun4i_can: sun4i_can_interrupt(): fix max irq loop handling
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Marc Kleine-Budde <mkl@pengutronix.de>
+
+commit 76544beea7cfe5bcce6d60f53811657b88ec8be1 upstream.
+
+Reading the interrupt register `SUN4I_REG_INT_ADDR` causes all of its bits
+to be reset. If we ever reach the condition of handling more than
+`SUN4I_CAN_MAX_IRQ` IRQs, we will have read the register and reset all its
+bits but without actually handling the interrupt inside of the loop body.
+
+This may, among other issues, cause us to never `netif_wake_queue()` again
+after a transmission interrupt.
+
+Fixes: 0738eff14d81 ("can: Allwinner A10/A20 CAN Controller support - Kernel module")
+Cc: stable@vger.kernel.org
+Co-developed-by: Thomas Mühlbacher <tmuehlbacher@posteo.net>
+Signed-off-by: Thomas Mühlbacher <tmuehlbacher@posteo.net>
+Acked-by: Jernej Skrabec <jernej.skrabec@gmail.com>
+Link: https://patch.msgid.link/20251116-sun4i-fix-loop-v1-1-3d76d3f81950@pengutronix.de
+Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/can/sun4i_can.c |    4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/drivers/net/can/sun4i_can.c
++++ b/drivers/net/can/sun4i_can.c
+@@ -657,8 +657,8 @@ static irqreturn_t sun4i_can_interrupt(i
+       u8 isrc, status;
+       int n = 0;
+-      while ((isrc = readl(priv->base + SUN4I_REG_INT_ADDR)) &&
+-             (n < SUN4I_CAN_MAX_IRQ)) {
++      while ((n < SUN4I_CAN_MAX_IRQ) &&
++             (isrc = readl(priv->base + SUN4I_REG_INT_ADDR))) {
+               n++;
+               status = readl(priv->base + SUN4I_REG_STA_ADDR);
diff --git a/queue-6.6/ceph-fix-crash-in-process_v2_sparse_read-for-encrypted-directories.patch b/queue-6.6/ceph-fix-crash-in-process_v2_sparse_read-for-encrypted-directories.patch
new file mode 100644 (file)
index 0000000..a9f564a
--- /dev/null
@@ -0,0 +1,373 @@
+From 43962db4a6f593903340c85591056a0cef812dfd Mon Sep 17 00:00:00 2001
+From: Viacheslav Dubeyko <Slava.Dubeyko@ibm.com>
+Date: Thu, 13 Nov 2025 14:36:24 -0800
+Subject: ceph: fix crash in process_v2_sparse_read() for encrypted directories
+
+From: Viacheslav Dubeyko <Slava.Dubeyko@ibm.com>
+
+commit 43962db4a6f593903340c85591056a0cef812dfd upstream.
+
+The crash in process_v2_sparse_read() for fscrypt-encrypted directories
+has been reported. Issue takes place for Ceph msgr2 protocol in secure
+mode. It can be reproduced by the steps:
+
+sudo mount -t ceph :/ /mnt/cephfs/ -o name=admin,fs=cephfs,ms_mode=secure
+
+(1) mkdir /mnt/cephfs/fscrypt-test-3
+(2) cp area_decrypted.tar /mnt/cephfs/fscrypt-test-3
+(3) fscrypt encrypt --source=raw_key --key=./my.key /mnt/cephfs/fscrypt-test-3
+(4) fscrypt lock /mnt/cephfs/fscrypt-test-3
+(5) fscrypt unlock --key=my.key /mnt/cephfs/fscrypt-test-3
+(6) cat /mnt/cephfs/fscrypt-test-3/area_decrypted.tar
+(7) Issue has been triggered
+
+[  408.072247] ------------[ cut here ]------------
+[  408.072251] WARNING: CPU: 1 PID: 392 at net/ceph/messenger_v2.c:865
+ceph_con_v2_try_read+0x4b39/0x72f0
+[  408.072267] Modules linked in: intel_rapl_msr intel_rapl_common
+intel_uncore_frequency_common intel_pmc_core pmt_telemetry pmt_discovery
+pmt_class intel_pmc_ssram_telemetry intel_vsec kvm_intel joydev kvm irqbypass
+polyval_clmulni ghash_clmulni_intel aesni_intel rapl input_leds psmouse
+serio_raw i2c_piix4 vga16fb bochs vgastate i2c_smbus floppy mac_hid qemu_fw_cfg
+pata_acpi sch_fq_codel rbd msr parport_pc ppdev lp parport efi_pstore
+[  408.072304] CPU: 1 UID: 0 PID: 392 Comm: kworker/1:3 Not tainted 6.17.0-rc7+
+[  408.072307] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
+1.17.0-5.fc42 04/01/2014
+[  408.072310] Workqueue: ceph-msgr ceph_con_workfn
+[  408.072314] RIP: 0010:ceph_con_v2_try_read+0x4b39/0x72f0
+[  408.072317] Code: c7 c1 20 f0 d4 ae 50 31 d2 48 c7 c6 60 27 d5 ae 48 c7 c7 f8
+8e 6f b0 68 60 38 d5 ae e8 00 47 61 fe 48 83 c4 18 e9 ac fc ff ff <0f> 0b e9 06
+fe ff ff 4c 8b 9d 98 fd ff ff 0f 84 64 e7 ff ff 89 85
+[  408.072319] RSP: 0018:ffff88811c3e7a30 EFLAGS: 00010246
+[  408.072322] RAX: ffffed1024874c6f RBX: ffffea00042c2b40 RCX: 0000000000000f38
+[  408.072324] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
+[  408.072325] RBP: ffff88811c3e7ca8 R08: 0000000000000000 R09: 00000000000000c8
+[  408.072326] R10: 00000000000000c8 R11: 0000000000000000 R12: 00000000000000c8
+[  408.072327] R13: dffffc0000000000 R14: ffff8881243a6030 R15: 0000000000003000
+[  408.072329] FS:  0000000000000000(0000) GS:ffff88823eadf000(0000)
+knlGS:0000000000000000
+[  408.072331] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
+[  408.072332] CR2: 000000c0003c6000 CR3: 000000010c106005 CR4: 0000000000772ef0
+[  408.072336] PKRU: 55555554
+[  408.072337] Call Trace:
+[  408.072338]  <TASK>
+[  408.072340]  ? sched_clock_noinstr+0x9/0x10
+[  408.072344]  ? __pfx_ceph_con_v2_try_read+0x10/0x10
+[  408.072347]  ? _raw_spin_unlock+0xe/0x40
+[  408.072349]  ? finish_task_switch.isra.0+0x15d/0x830
+[  408.072353]  ? __kasan_check_write+0x14/0x30
+[  408.072357]  ? mutex_lock+0x84/0xe0
+[  408.072359]  ? __pfx_mutex_lock+0x10/0x10
+[  408.072361]  ceph_con_workfn+0x27e/0x10e0
+[  408.072364]  ? metric_delayed_work+0x311/0x2c50
+[  408.072367]  process_one_work+0x611/0xe20
+[  408.072371]  ? __kasan_check_write+0x14/0x30
+[  408.072373]  worker_thread+0x7e3/0x1580
+[  408.072375]  ? __pfx__raw_spin_lock_irqsave+0x10/0x10
+[  408.072378]  ? __pfx_worker_thread+0x10/0x10
+[  408.072381]  kthread+0x381/0x7a0
+[  408.072383]  ? __pfx__raw_spin_lock_irq+0x10/0x10
+[  408.072385]  ? __pfx_kthread+0x10/0x10
+[  408.072387]  ? __kasan_check_write+0x14/0x30
+[  408.072389]  ? recalc_sigpending+0x160/0x220
+[  408.072392]  ? _raw_spin_unlock_irq+0xe/0x50
+[  408.072394]  ? calculate_sigpending+0x78/0xb0
+[  408.072395]  ? __pfx_kthread+0x10/0x10
+[  408.072397]  ret_from_fork+0x2b6/0x380
+[  408.072400]  ? __pfx_kthread+0x10/0x10
+[  408.072402]  ret_from_fork_asm+0x1a/0x30
+[  408.072406]  </TASK>
+[  408.072407] ---[ end trace 0000000000000000 ]---
+[  408.072418] Oops: general protection fault, probably for non-canonical
+address 0xdffffc0000000000: 0000 [#1] SMP KASAN NOPTI
+[  408.072984] KASAN: null-ptr-deref in range [0x0000000000000000-
+0x0000000000000007]
+[  408.073350] CPU: 1 UID: 0 PID: 392 Comm: kworker/1:3 Tainted: G        W
+6.17.0-rc7+ #1 PREEMPT(voluntary)
+[  408.073886] Tainted: [W]=WARN
+[  408.074042] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
+1.17.0-5.fc42 04/01/2014
+[  408.074468] Workqueue: ceph-msgr ceph_con_workfn
+[  408.074694] RIP: 0010:ceph_msg_data_advance+0x79/0x1a80
+[  408.074976] Code: fc ff df 49 8d 77 08 48 c1 ee 03 80 3c 16 00 0f 85 07 11 00
+00 48 ba 00 00 00 00 00 fc ff df 49 8b 5f 08 48 89 de 48 c1 ee 03 <0f> b6 14 16
+84 d2 74 09 80 fa 03 0f 8e 0f 0e 00 00 8b 13 83 fa 03
+[  408.075884] RSP: 0018:ffff88811c3e7990 EFLAGS: 00010246
+[  408.076305] RAX: ffff8881243a6388 RBX: 0000000000000000 RCX: 0000000000000000
+[  408.076909] RDX: dffffc0000000000 RSI: 0000000000000000 RDI: ffff8881243a6378
+[  408.077466] RBP: ffff88811c3e7a20 R08: 0000000000000000 R09: 00000000000000c8
+[  408.078034] R10: ffff8881243a6388 R11: 0000000000000000 R12: ffffed1024874c71
+[  408.078575] R13: dffffc0000000000 R14: ffff8881243a6030 R15: ffff8881243a6378
+[  408.079159] FS:  0000000000000000(0000) GS:ffff88823eadf000(0000)
+knlGS:0000000000000000
+[  408.079736] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
+[  408.080039] CR2: 000000c0003c6000 CR3: 000000010c106005 CR4: 0000000000772ef0
+[  408.080376] PKRU: 55555554
+[  408.080513] Call Trace:
+[  408.080630]  <TASK>
+[  408.080729]  ceph_con_v2_try_read+0x49b9/0x72f0
+[  408.081115]  ? __pfx_ceph_con_v2_try_read+0x10/0x10
+[  408.081348]  ? _raw_spin_unlock+0xe/0x40
+[  408.081538]  ? finish_task_switch.isra.0+0x15d/0x830
+[  408.081768]  ? __kasan_check_write+0x14/0x30
+[  408.081986]  ? mutex_lock+0x84/0xe0
+[  408.082160]  ? __pfx_mutex_lock+0x10/0x10
+[  408.082343]  ceph_con_workfn+0x27e/0x10e0
+[  408.082529]  ? metric_delayed_work+0x311/0x2c50
+[  408.082737]  process_one_work+0x611/0xe20
+[  408.082948]  ? __kasan_check_write+0x14/0x30
+[  408.083156]  worker_thread+0x7e3/0x1580
+[  408.083331]  ? __pfx__raw_spin_lock_irqsave+0x10/0x10
+[  408.083557]  ? __pfx_worker_thread+0x10/0x10
+[  408.083751]  kthread+0x381/0x7a0
+[  408.083922]  ? __pfx__raw_spin_lock_irq+0x10/0x10
+[  408.084139]  ? __pfx_kthread+0x10/0x10
+[  408.084310]  ? __kasan_check_write+0x14/0x30
+[  408.084510]  ? recalc_sigpending+0x160/0x220
+[  408.084708]  ? _raw_spin_unlock_irq+0xe/0x50
+[  408.084917]  ? calculate_sigpending+0x78/0xb0
+[  408.085138]  ? __pfx_kthread+0x10/0x10
+[  408.085335]  ret_from_fork+0x2b6/0x380
+[  408.085525]  ? __pfx_kthread+0x10/0x10
+[  408.085720]  ret_from_fork_asm+0x1a/0x30
+[  408.085922]  </TASK>
+[  408.086036] Modules linked in: intel_rapl_msr intel_rapl_common
+intel_uncore_frequency_common intel_pmc_core pmt_telemetry pmt_discovery
+pmt_class intel_pmc_ssram_telemetry intel_vsec kvm_intel joydev kvm irqbypass
+polyval_clmulni ghash_clmulni_intel aesni_intel rapl input_leds psmouse
+serio_raw i2c_piix4 vga16fb bochs vgastate i2c_smbus floppy mac_hid qemu_fw_cfg
+pata_acpi sch_fq_codel rbd msr parport_pc ppdev lp parport efi_pstore
+[  408.087778] ---[ end trace 0000000000000000 ]---
+[  408.088007] RIP: 0010:ceph_msg_data_advance+0x79/0x1a80
+[  408.088260] Code: fc ff df 49 8d 77 08 48 c1 ee 03 80 3c 16 00 0f 85 07 11 00
+00 48 ba 00 00 00 00 00 fc ff df 49 8b 5f 08 48 89 de 48 c1 ee 03 <0f> b6 14 16
+84 d2 74 09 80 fa 03 0f 8e 0f 0e 00 00 8b 13 83 fa 03
+[  408.089118] RSP: 0018:ffff88811c3e7990 EFLAGS: 00010246
+[  408.089357] RAX: ffff8881243a6388 RBX: 0000000000000000 RCX: 0000000000000000
+[  408.089678] RDX: dffffc0000000000 RSI: 0000000000000000 RDI: ffff8881243a6378
+[  408.090020] RBP: ffff88811c3e7a20 R08: 0000000000000000 R09: 00000000000000c8
+[  408.090360] R10: ffff8881243a6388 R11: 0000000000000000 R12: ffffed1024874c71
+[  408.090687] R13: dffffc0000000000 R14: ffff8881243a6030 R15: ffff8881243a6378
+[  408.091035] FS:  0000000000000000(0000) GS:ffff88823eadf000(0000)
+knlGS:0000000000000000
+[  408.091452] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
+[  408.092015] CR2: 000000c0003c6000 CR3: 000000010c106005 CR4: 0000000000772ef0
+[  408.092530] PKRU: 55555554
+[  417.112915]
+==================================================================
+[  417.113491] BUG: KASAN: slab-use-after-free in
+__mutex_lock.constprop.0+0x1522/0x1610
+[  417.114014] Read of size 4 at addr ffff888124870034 by task kworker/2:0/4951
+
+[  417.114587] CPU: 2 UID: 0 PID: 4951 Comm: kworker/2:0 Tainted: G      D W
+6.17.0-rc7+ #1 PREEMPT(voluntary)
+[  417.114592] Tainted: [D]=DIE, [W]=WARN
+[  417.114593] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
+1.17.0-5.fc42 04/01/2014
+[  417.114596] Workqueue: events handle_timeout
+[  417.114601] Call Trace:
+[  417.114602]  <TASK>
+[  417.114604]  dump_stack_lvl+0x5c/0x90
+[  417.114610]  print_report+0x171/0x4dc
+[  417.114613]  ? __pfx__raw_spin_lock_irqsave+0x10/0x10
+[  417.114617]  ? kasan_complete_mode_report_info+0x80/0x220
+[  417.114621]  kasan_report+0xbd/0x100
+[  417.114625]  ? __mutex_lock.constprop.0+0x1522/0x1610
+[  417.114628]  ? __mutex_lock.constprop.0+0x1522/0x1610
+[  417.114630]  __asan_report_load4_noabort+0x14/0x30
+[  417.114633]  __mutex_lock.constprop.0+0x1522/0x1610
+[  417.114635]  ? queue_con_delay+0x8d/0x200
+[  417.114638]  ? __pfx___mutex_lock.constprop.0+0x10/0x10
+[  417.114641]  ? __send_subscribe+0x529/0xb20
+[  417.114644]  __mutex_lock_slowpath+0x13/0x20
+[  417.114646]  mutex_lock+0xd4/0xe0
+[  417.114649]  ? __pfx_mutex_lock+0x10/0x10
+[  417.114652]  ? ceph_monc_renew_subs+0x2a/0x40
+[  417.114654]  ceph_con_keepalive+0x22/0x110
+[  417.114656]  handle_timeout+0x6b3/0x11d0
+[  417.114659]  ? _raw_spin_unlock_irq+0xe/0x50
+[  417.114662]  ? __pfx_handle_timeout+0x10/0x10
+[  417.114664]  ? queue_delayed_work_on+0x8e/0xa0
+[  417.114669]  process_one_work+0x611/0xe20
+[  417.114672]  ? __kasan_check_write+0x14/0x30
+[  417.114676]  worker_thread+0x7e3/0x1580
+[  417.114678]  ? __pfx__raw_spin_lock_irqsave+0x10/0x10
+[  417.114682]  ? __pfx_sched_setscheduler_nocheck+0x10/0x10
+[  417.114687]  ? __pfx_worker_thread+0x10/0x10
+[  417.114689]  kthread+0x381/0x7a0
+[  417.114692]  ? __pfx__raw_spin_lock_irq+0x10/0x10
+[  417.114694]  ? __pfx_kthread+0x10/0x10
+[  417.114697]  ? __kasan_check_write+0x14/0x30
+[  417.114699]  ? recalc_sigpending+0x160/0x220
+[  417.114703]  ? _raw_spin_unlock_irq+0xe/0x50
+[  417.114705]  ? calculate_sigpending+0x78/0xb0
+[  417.114707]  ? __pfx_kthread+0x10/0x10
+[  417.114710]  ret_from_fork+0x2b6/0x380
+[  417.114713]  ? __pfx_kthread+0x10/0x10
+[  417.114715]  ret_from_fork_asm+0x1a/0x30
+[  417.114720]  </TASK>
+
+[  417.125171] Allocated by task 2:
+[  417.125333]  kasan_save_stack+0x26/0x60
+[  417.125522]  kasan_save_track+0x14/0x40
+[  417.125742]  kasan_save_alloc_info+0x39/0x60
+[  417.125945]  __kasan_slab_alloc+0x8b/0xb0
+[  417.126133]  kmem_cache_alloc_node_noprof+0x13b/0x460
+[  417.126381]  copy_process+0x320/0x6250
+[  417.126595]  kernel_clone+0xb7/0x840
+[  417.126792]  kernel_thread+0xd6/0x120
+[  417.126995]  kthreadd+0x85c/0xbe0
+[  417.127176]  ret_from_fork+0x2b6/0x380
+[  417.127378]  ret_from_fork_asm+0x1a/0x30
+
+[  417.127692] Freed by task 0:
+[  417.127851]  kasan_save_stack+0x26/0x60
+[  417.128057]  kasan_save_track+0x14/0x40
+[  417.128267]  kasan_save_free_info+0x3b/0x60
+[  417.128491]  __kasan_slab_free+0x6c/0xa0
+[  417.128708]  kmem_cache_free+0x182/0x550
+[  417.128906]  free_task+0xeb/0x140
+[  417.129070]  __put_task_struct+0x1d2/0x4f0
+[  417.129259]  __put_task_struct_rcu_cb+0x15/0x20
+[  417.129480]  rcu_do_batch+0x3d3/0xe70
+[  417.129681]  rcu_core+0x549/0xb30
+[  417.129839]  rcu_core_si+0xe/0x20
+[  417.130005]  handle_softirqs+0x160/0x570
+[  417.130190]  __irq_exit_rcu+0x189/0x1e0
+[  417.130369]  irq_exit_rcu+0xe/0x20
+[  417.130531]  sysvec_apic_timer_interrupt+0x9f/0xd0
+[  417.130768]  asm_sysvec_apic_timer_interrupt+0x1b/0x20
+
+[  417.131082] Last potentially related work creation:
+[  417.131305]  kasan_save_stack+0x26/0x60
+[  417.131484]  kasan_record_aux_stack+0xae/0xd0
+[  417.131695]  __call_rcu_common+0xcd/0x14b0
+[  417.131909]  call_rcu+0x31/0x50
+[  417.132071]  delayed_put_task_struct+0x128/0x190
+[  417.132295]  rcu_do_batch+0x3d3/0xe70
+[  417.132478]  rcu_core+0x549/0xb30
+[  417.132658]  rcu_core_si+0xe/0x20
+[  417.132808]  handle_softirqs+0x160/0x570
+[  417.132993]  __irq_exit_rcu+0x189/0x1e0
+[  417.133181]  irq_exit_rcu+0xe/0x20
+[  417.133353]  sysvec_apic_timer_interrupt+0x9f/0xd0
+[  417.133584]  asm_sysvec_apic_timer_interrupt+0x1b/0x20
+
+[  417.133921] Second to last potentially related work creation:
+[  417.134183]  kasan_save_stack+0x26/0x60
+[  417.134362]  kasan_record_aux_stack+0xae/0xd0
+[  417.134566]  __call_rcu_common+0xcd/0x14b0
+[  417.134782]  call_rcu+0x31/0x50
+[  417.134929]  put_task_struct_rcu_user+0x58/0xb0
+[  417.135143]  finish_task_switch.isra.0+0x5d3/0x830
+[  417.135366]  __schedule+0xd30/0x5100
+[  417.135534]  schedule_idle+0x5a/0x90
+[  417.135712]  do_idle+0x25f/0x410
+[  417.135871]  cpu_startup_entry+0x53/0x70
+[  417.136053]  start_secondary+0x216/0x2c0
+[  417.136233]  common_startup_64+0x13e/0x141
+
+[  417.136894] The buggy address belongs to the object at ffff888124870000
+                which belongs to the cache task_struct of size 10504
+[  417.138122] The buggy address is located 52 bytes inside of
+                freed 10504-byte region [ffff888124870000, ffff888124872908)
+
+[  417.139465] The buggy address belongs to the physical page:
+[  417.140016] page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0
+pfn:0x124870
+[  417.140789] head: order:3 mapcount:0 entire_mapcount:0 nr_pages_mapped:0
+pincount:0
+[  417.141519] memcg:ffff88811aa20e01
+[  417.141874] anon flags:
+0x17ffffc0000040(head|node=0|zone=2|lastcpupid=0x1fffff)
+[  417.142600] page_type: f5(slab)
+[  417.142922] raw: 0017ffffc0000040 ffff88810094f040 0000000000000000
+dead000000000001
+[  417.143554] raw: 0000000000000000 0000000000030003 00000000f5000000
+ffff88811aa20e01
+[  417.143954] head: 0017ffffc0000040 ffff88810094f040 0000000000000000
+dead000000000001
+[  417.144329] head: 0000000000000000 0000000000030003 00000000f5000000
+ffff88811aa20e01
+[  417.144710] head: 0017ffffc0000003 ffffea0004921c01 00000000ffffffff
+00000000ffffffff
+[  417.145106] head: ffffffffffffffff 0000000000000000 00000000ffffffff
+0000000000000008
+[  417.145485] page dumped because: kasan: bad access detected
+
+[  417.145859] Memory state around the buggy address:
+[  417.146094]  ffff88812486ff00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
+fc
+[  417.146439]  ffff88812486ff80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
+fc
+[  417.146791] >ffff888124870000: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb
+fb
+[  417.147145]                                      ^
+[  417.147387]  ffff888124870080: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
+fb
+[  417.147751]  ffff888124870100: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
+fb
+[  417.148123]
+==================================================================
+
+First of all, we have warning in get_bvec_at() because
+cursor->total_resid contains zero value. And, finally,
+we have crash in ceph_msg_data_advance() because
+cursor->data is NULL. It means that get_bvec_at()
+receives not initialized ceph_msg_data_cursor structure
+because data is NULL and total_resid contains zero.
+
+Moreover, we don't have likewise issue for the case of
+Ceph msgr1 protocol because ceph_msg_data_cursor_init()
+has been called before reading sparse data.
+
+This patch adds calling of ceph_msg_data_cursor_init()
+in the beginning of process_v2_sparse_read() with
+the goal to guarantee that logic of reading sparse data
+works correctly for the case of Ceph msgr2 protocol.
+
+Cc: stable@vger.kernel.org
+Link: https://tracker.ceph.com/issues/73152
+Signed-off-by: Viacheslav Dubeyko <Slava.Dubeyko@ibm.com>
+Reviewed-by: Ilya Dryomov <idryomov@gmail.com>
+Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/ceph/messenger_v2.c |   11 +++++++----
+ 1 file changed, 7 insertions(+), 4 deletions(-)
+
+--- a/net/ceph/messenger_v2.c
++++ b/net/ceph/messenger_v2.c
+@@ -1091,13 +1091,16 @@ static int decrypt_control_remainder(str
+ static int process_v2_sparse_read(struct ceph_connection *con,
+                                 struct page **pages, int spos)
+ {
+-      struct ceph_msg_data_cursor *cursor = &con->v2.in_cursor;
++      struct ceph_msg_data_cursor cursor;
+       int ret;
++      ceph_msg_data_cursor_init(&cursor, con->in_msg,
++                                con->in_msg->sparse_read_total);
++
+       for (;;) {
+               char *buf = NULL;
+-              ret = con->ops->sparse_read(con, cursor, &buf);
++              ret = con->ops->sparse_read(con, &cursor, &buf);
+               if (ret <= 0)
+                       return ret;
+@@ -1115,11 +1118,11 @@ static int process_v2_sparse_read(struct
+                       } else {
+                               struct bio_vec bv;
+-                              get_bvec_at(cursor, &bv);
++                              get_bvec_at(&cursor, &bv);
+                               len = min_t(int, len, bv.bv_len);
+                               memcpy_page(bv.bv_page, bv.bv_offset,
+                                           spage, soff, len);
+-                              ceph_msg_data_advance(cursor, len);
++                              ceph_msg_data_advance(&cursor, len);
+                       }
+                       spos += len;
+                       ret -= len;
diff --git a/queue-6.6/dm-verity-fix-unreliable-memory-allocation.patch b/queue-6.6/dm-verity-fix-unreliable-memory-allocation.patch
new file mode 100644 (file)
index 0000000..70d7057
--- /dev/null
@@ -0,0 +1,36 @@
+From fe680d8c747f4e676ac835c8c7fb0f287cd98758 Mon Sep 17 00:00:00 2001
+From: Mikulas Patocka <mpatocka@redhat.com>
+Date: Mon, 17 Nov 2025 21:42:02 +0100
+Subject: dm-verity: fix unreliable memory allocation
+
+From: Mikulas Patocka <mpatocka@redhat.com>
+
+commit fe680d8c747f4e676ac835c8c7fb0f287cd98758 upstream.
+
+GFP_NOWAIT allocation may fail anytime. It needs to be changed to
+GFP_NOIO. There's no need to handle an error because mempool_alloc with
+GFP_NOIO can't fail.
+
+Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
+Cc: stable@vger.kernel.org
+Reviewed-by: Eric Biggers <ebiggers@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/md/dm-verity-fec.c |    6 +-----
+ 1 file changed, 1 insertion(+), 5 deletions(-)
+
+--- a/drivers/md/dm-verity-fec.c
++++ b/drivers/md/dm-verity-fec.c
+@@ -330,11 +330,7 @@ static int fec_alloc_bufs(struct dm_veri
+               if (fio->bufs[n])
+                       continue;
+-              fio->bufs[n] = mempool_alloc(&v->fec->prealloc_pool, GFP_NOWAIT);
+-              if (unlikely(!fio->bufs[n])) {
+-                      DMERR("failed to allocate FEC buffer");
+-                      return -ENOMEM;
+-              }
++              fio->bufs[n] = mempool_alloc(&v->fec->prealloc_pool, GFP_NOIO);
+       }
+       /* try to allocate the maximum number of buffers */
diff --git a/queue-6.6/drivers-usb-dwc3-fix-pci-parent-check.patch b/queue-6.6/drivers-usb-dwc3-fix-pci-parent-check.patch
new file mode 100644 (file)
index 0000000..5dba6d5
--- /dev/null
@@ -0,0 +1,48 @@
+From 40f8d17eed7533ed2bbb5e3cc680049b19411b2e Mon Sep 17 00:00:00 2001
+From: Jamie Iles <jamie.iles@oss.qualcomm.com>
+Date: Fri, 7 Nov 2025 10:44:37 +0000
+Subject: drivers/usb/dwc3: fix PCI parent check
+
+From: Jamie Iles <jamie.iles@oss.qualcomm.com>
+
+commit 40f8d17eed7533ed2bbb5e3cc680049b19411b2e upstream.
+
+The sysdev_is_parent check was being used to infer PCI devices that have
+the DMA mask set from the PCI capabilities, but sysdev_is_parent is also
+used for non-PCI ACPI devices in which case the DMA mask would be the
+bus default or as set by the _DMA method.
+
+Without this fix the DMA mask would default to 32-bits and so allocation
+would fail if there was no DRAM below 4GB.
+
+Fixes: 47ce45906ca9 ("usb: dwc3: leave default DMA for PCI devices")
+Cc: stable <stable@kernel.org>
+Signed-off-by: Jamie Iles <jamie.iles@oss.qualcomm.com>
+Signed-off-by: Punit Agrawal <punit.agrawal@oss.qualcomm.com>
+Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
+Link: https://patch.msgid.link/20251107104437.1602509-1-punit.agrawal@oss.qualcomm.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/usb/dwc3/core.c |    3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/drivers/usb/dwc3/core.c
++++ b/drivers/usb/dwc3/core.c
+@@ -25,6 +25,7 @@
+ #include <linux/of.h>
+ #include <linux/of_graph.h>
+ #include <linux/acpi.h>
++#include <linux/pci.h>
+ #include <linux/pinctrl/consumer.h>
+ #include <linux/reset.h>
+ #include <linux/bitfield.h>
+@@ -1990,7 +1991,7 @@ static int dwc3_probe(struct platform_de
+       platform_set_drvdata(pdev, dwc);
+       dwc3_cache_hwparams(dwc);
+-      if (!dwc->sysdev_is_parent &&
++      if (!dev_is_pci(dwc->sysdev) &&
+           DWC3_GHWPARAMS0_AWIDTH(dwc->hwparams.hwparams0) == 64) {
+               ret = dma_set_mask_and_coherent(dwc->sysdev, DMA_BIT_MASK(64));
+               if (ret)
diff --git a/queue-6.6/firmware-stratix10-svc-fix-bug-in-saving-controller-data.patch b/queue-6.6/firmware-stratix10-svc-fix-bug-in-saving-controller-data.patch
new file mode 100644 (file)
index 0000000..da6fde4
--- /dev/null
@@ -0,0 +1,69 @@
+From d0fcf70c680e4d1669fcb3a8632f41400b9a73c2 Mon Sep 17 00:00:00 2001
+From: Khairul Anuar Romli <khairul.anuar.romli@altera.com>
+Date: Mon, 3 Nov 2025 07:21:28 +0800
+Subject: firmware: stratix10-svc: fix bug in saving controller data
+
+From: Khairul Anuar Romli <khairul.anuar.romli@altera.com>
+
+commit d0fcf70c680e4d1669fcb3a8632f41400b9a73c2 upstream.
+
+Fix the incorrect usage of platform_set_drvdata and dev_set_drvdata. They
+both are of the same data and overrides each other. This resulted in the
+rmmod of the svc driver to fail and throw a kernel panic for kthread_stop
+and fifo free.
+
+Fixes: b5dc75c915cd ("firmware: stratix10-svc: extend svc to support new RSU features")
+Cc: stable@vger.kernel.org # 6.6+
+Signed-off-by: Ang Tien Sung <tiensung.ang@altera.com>
+Signed-off-by: Khairul Anuar Romli <khairul.anuar.romli@altera.com>
+Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/firmware/stratix10-svc.c |    7 ++++---
+ 1 file changed, 4 insertions(+), 3 deletions(-)
+
+--- a/drivers/firmware/stratix10-svc.c
++++ b/drivers/firmware/stratix10-svc.c
+@@ -134,6 +134,7 @@ struct stratix10_svc_data {
+  * @complete_status: state for completion
+  * @svc_fifo_lock: protect access to service message data queue
+  * @invoke_fn: function to issue secure monitor call or hypervisor call
++ * @svc: manages the list of client svc drivers
+  *
+  * This struct is used to create communication channels for service clients, to
+  * handle secure monitor or hypervisor call.
+@@ -150,6 +151,7 @@ struct stratix10_svc_controller {
+       struct completion complete_status;
+       spinlock_t svc_fifo_lock;
+       svc_invoke_fn *invoke_fn;
++      struct stratix10_svc *svc;
+ };
+ /**
+@@ -1209,6 +1211,7 @@ static int stratix10_svc_drv_probe(struc
+               ret = -ENOMEM;
+               goto err_free_kfifo;
+       }
++      controller->svc = svc;
+       svc->stratix10_svc_rsu = platform_device_alloc(STRATIX10_RSU, 0);
+       if (!svc->stratix10_svc_rsu) {
+@@ -1236,8 +1239,6 @@ static int stratix10_svc_drv_probe(struc
+               goto err_unregister_dev;
+       }
+-      dev_set_drvdata(dev, svc);
+-
+       pr_info("Intel Service Layer Driver Initialized\n");
+       return 0;
+@@ -1253,8 +1254,8 @@ err_destroy_pool:
+ static int stratix10_svc_drv_remove(struct platform_device *pdev)
+ {
+-      struct stratix10_svc *svc = dev_get_drvdata(&pdev->dev);
+       struct stratix10_svc_controller *ctrl = platform_get_drvdata(pdev);
++      struct stratix10_svc *svc = ctrl->svc;
+       platform_device_unregister(svc->intel_svc_fcs);
+       platform_device_unregister(svc->stratix10_svc_rsu);
diff --git a/queue-6.6/mptcp-clear-scheduled-subflows-on-retransmit.patch b/queue-6.6/mptcp-clear-scheduled-subflows-on-retransmit.patch
new file mode 100644 (file)
index 0000000..dfbc192
--- /dev/null
@@ -0,0 +1,68 @@
+From 27fd02860164bfa78cec2640dfad630d832e302c Mon Sep 17 00:00:00 2001
+From: Paolo Abeni <pabeni@redhat.com>
+Date: Tue, 25 Nov 2025 17:59:11 +0100
+Subject: mptcp: clear scheduled subflows on retransmit
+
+From: Paolo Abeni <pabeni@redhat.com>
+
+commit 27fd02860164bfa78cec2640dfad630d832e302c upstream.
+
+When __mptcp_retrans() kicks-in, it schedules one or more subflows for
+retransmission, but such subflows could be actually left alone if there
+is no more data to retransmit and/or in case of concurrent fallback.
+
+Scheduled subflows could be processed much later in time, i.e. when new
+data will be transmitted, leading to bad subflow selection.
+
+Explicitly clear all scheduled subflows before leaving the
+retransmission function.
+
+Fixes: ee2708aedad0 ("mptcp: use get_retrans wrapper")
+Cc: stable@vger.kernel.org
+Reported-by: Filip Pokryvka <fpokryvk@redhat.com>
+Signed-off-by: Paolo Abeni <pabeni@redhat.com>
+Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
+Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
+Link: https://patch.msgid.link/20251125-net-mptcp-clear-sched-rtx-v1-1-1cea4ad2165f@kernel.org
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/mptcp/protocol.c |   13 +++++++++++--
+ 1 file changed, 11 insertions(+), 2 deletions(-)
+
+--- a/net/mptcp/protocol.c
++++ b/net/mptcp/protocol.c
+@@ -2691,7 +2691,7 @@ static void __mptcp_retrans(struct sock
+               }
+               if (!mptcp_send_head(sk))
+-                      return;
++                      goto clear_scheduled;
+               goto reset_timer;
+       }
+@@ -2722,7 +2722,7 @@ static void __mptcp_retrans(struct sock
+                       if (__mptcp_check_fallback(msk)) {
+                               spin_unlock_bh(&msk->fallback_lock);
+                               release_sock(ssk);
+-                              return;
++                              goto clear_scheduled;
+                       }
+                       while (info.sent < info.limit) {
+@@ -2754,6 +2754,15 @@ reset_timer:
+       if (!mptcp_rtx_timer_pending(sk))
+               mptcp_reset_rtx_timer(sk);
++
++clear_scheduled:
++      /* If no rtx data was available or in case of fallback, there
++       * could be left-over scheduled subflows; clear them all
++       * or later xmit could use bad ones
++       */
++      mptcp_for_each_subflow(msk, subflow)
++              if (READ_ONCE(subflow->scheduled))
++                      mptcp_subflow_set_scheduled(subflow, false);
+ }
+ /* schedule the timeout timer for the relevant event: either close timeout
diff --git a/queue-6.6/serial-amba-pl011-prefer-dma_mapping_error-over-explicit-address-checking.patch b/queue-6.6/serial-amba-pl011-prefer-dma_mapping_error-over-explicit-address-checking.patch
new file mode 100644 (file)
index 0000000..bb2daae
--- /dev/null
@@ -0,0 +1,41 @@
+From eb4917f557d43c7a1c805dd73ffcdfddb2aba39a Mon Sep 17 00:00:00 2001
+From: Miaoqian Lin <linmq006@gmail.com>
+Date: Mon, 27 Oct 2025 17:20:50 +0800
+Subject: serial: amba-pl011: prefer dma_mapping_error() over explicit address checking
+
+From: Miaoqian Lin <linmq006@gmail.com>
+
+commit eb4917f557d43c7a1c805dd73ffcdfddb2aba39a upstream.
+
+Check for returned DMA addresses using specialized dma_mapping_error()
+helper which is generally recommended for this purpose by
+Documentation/core-api/dma-api.rst:
+
+  "In some circumstances dma_map_single(), ...
+will fail to create a mapping. A driver can check for these errors
+by testing the returned DMA address with dma_mapping_error()."
+
+Found via static analysis and this is similar to commit fa0308134d26
+("ALSA: memalloc: prefer dma_mapping_error() over explicit address checking")
+
+Fixes: 58ac1b379979 ("ARM: PL011: Fix DMA support")
+Cc: stable <stable@kernel.org>
+Signed-off-by: Miaoqian Lin <linmq006@gmail.com>
+Reviewed-by: Gregory CLEMENT <gregory.clement@bootlin.com>
+Link: https://patch.msgid.link/20251027092053.87937-1-linmq006@gmail.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/tty/serial/amba-pl011.c |    2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/tty/serial/amba-pl011.c
++++ b/drivers/tty/serial/amba-pl011.c
+@@ -636,7 +636,7 @@ static int pl011_dma_tx_refill(struct ua
+       dmatx->len = count;
+       dmatx->dma = dma_map_single(dma_dev->dev, dmatx->buf, count,
+                                   DMA_TO_DEVICE);
+-      if (dmatx->dma == DMA_MAPPING_ERROR) {
++      if (dma_mapping_error(dma_dev->dev, dmatx->dma)) {
+               uap->dmatx.queued = false;
+               dev_dbg(uap->port.dev, "unable to map TX DMA\n");
+               return -EBUSY;
index 7de6028a01d4cf8a350a777f2c77e71caf461076..b1abc3e582c88e0299fc3be55c814f87cd7536da 100644 (file)
@@ -39,3 +39,17 @@ iio-accel-fix-adxl355-startup-race-condition.patch
 iio-adc-ad7280a-fix-ad7280_store_balance_timer.patch
 mips-mm-prevent-a-tlb-shutdown-on-initial-uniquification.patch
 mips-mm-kmalloc-tlb_vpn-array-to-avoid-stack-overflow.patch
+alsa-usb-audio-add-dsd-quirk-for-leak-stereo-230.patch
+arm-dts-nxp-imx6ul-correct-sai3-interrupt-line.patch
+atm-fore200e-fix-possible-data-race-in-fore200e_open.patch
+can-sja1000-fix-max-irq-loop-handling.patch
+can-sun4i_can-sun4i_can_interrupt-fix-max-irq-loop-handling.patch
+ceph-fix-crash-in-process_v2_sparse_read-for-encrypted-directories.patch
+dm-verity-fix-unreliable-memory-allocation.patch
+drivers-usb-dwc3-fix-pci-parent-check.patch
+smb-client-fix-memory-leak-in-cifs_construct_tcon.patch
+thunderbolt-add-support-for-intel-wildcat-lake.patch
+slimbus-ngd-fix-reference-count-leak-in-qcom_slim_ngd_notify_slaves.patch
+firmware-stratix10-svc-fix-bug-in-saving-controller-data.patch
+mptcp-clear-scheduled-subflows-on-retransmit.patch
+serial-amba-pl011-prefer-dma_mapping_error-over-explicit-address-checking.patch
diff --git a/queue-6.6/slimbus-ngd-fix-reference-count-leak-in-qcom_slim_ngd_notify_slaves.patch b/queue-6.6/slimbus-ngd-fix-reference-count-leak-in-qcom_slim_ngd_notify_slaves.patch
new file mode 100644 (file)
index 0000000..9b606d2
--- /dev/null
@@ -0,0 +1,38 @@
+From 96cf8500934e0ce2a6c486f1dbc3b1fff12f7a5e Mon Sep 17 00:00:00 2001
+From: Miaoqian Lin <linmq006@gmail.com>
+Date: Mon, 27 Oct 2025 14:06:01 +0800
+Subject: slimbus: ngd: Fix reference count leak in qcom_slim_ngd_notify_slaves
+
+From: Miaoqian Lin <linmq006@gmail.com>
+
+commit 96cf8500934e0ce2a6c486f1dbc3b1fff12f7a5e upstream.
+
+The function qcom_slim_ngd_notify_slaves() calls of_slim_get_device() which
+internally uses device_find_child() to obtain a device reference.
+According to the device_find_child() documentation,
+the caller must drop the reference with put_device() after use.
+
+Found via static analysis and this is similar to commit 4e65bda8273c
+("ASoC: wcd934x: fix error handling in wcd934x_codec_parse_data()")
+
+Fixes: 917809e2280b ("slimbus: ngd: Add qcom SLIMBus NGD driver")
+Cc: stable <stable@kernel.org>
+Signed-off-by: Miaoqian Lin <linmq006@gmail.com>
+Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
+Link: https://patch.msgid.link/20251027060601.33228-1-linmq006@gmail.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/slimbus/qcom-ngd-ctrl.c |    1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/slimbus/qcom-ngd-ctrl.c
++++ b/drivers/slimbus/qcom-ngd-ctrl.c
+@@ -1239,6 +1239,7 @@ static void qcom_slim_ngd_notify_slaves(
+               if (slim_get_logical_addr(sbdev))
+                       dev_err(ctrl->dev, "Failed to get logical address\n");
++              put_device(&sbdev->dev);
+       }
+ }
diff --git a/queue-6.6/smb-client-fix-memory-leak-in-cifs_construct_tcon.patch b/queue-6.6/smb-client-fix-memory-leak-in-cifs_construct_tcon.patch
new file mode 100644 (file)
index 0000000..747c464
--- /dev/null
@@ -0,0 +1,65 @@
+From 3184b6a5a24ec9ee74087b2a550476f386df7dc2 Mon Sep 17 00:00:00 2001
+From: Paulo Alcantara <pc@manguebit.org>
+Date: Mon, 24 Nov 2025 17:00:36 -0300
+Subject: smb: client: fix memory leak in cifs_construct_tcon()
+
+From: Paulo Alcantara <pc@manguebit.org>
+
+commit 3184b6a5a24ec9ee74087b2a550476f386df7dc2 upstream.
+
+When having a multiuser mount with domain= specified and using
+cifscreds, cifs_set_cifscreds() will end up setting @ctx->domainname,
+so it needs to be freed before leaving cifs_construct_tcon().
+
+This fixes the following memory leak reported by kmemleak:
+
+  mount.cifs //srv/share /mnt -o domain=ZELDA,multiuser,...
+  su - testuser
+  cifscreds add -d ZELDA -u testuser
+  ...
+  ls /mnt/1
+  ...
+  umount /mnt
+  echo scan > /sys/kernel/debug/kmemleak
+  cat /sys/kernel/debug/kmemleak
+  unreferenced object 0xffff8881203c3f08 (size 8):
+    comm "ls", pid 5060, jiffies 4307222943
+    hex dump (first 8 bytes):
+      5a 45 4c 44 41 00 cc cc                          ZELDA...
+    backtrace (crc d109a8cf):
+      __kmalloc_node_track_caller_noprof+0x572/0x710
+      kstrdup+0x3a/0x70
+      cifs_sb_tlink+0x1209/0x1770 [cifs]
+      cifs_get_fattr+0xe1/0xf50 [cifs]
+      cifs_get_inode_info+0xb5/0x240 [cifs]
+      cifs_revalidate_dentry_attr+0x2d1/0x470 [cifs]
+      cifs_getattr+0x28e/0x450 [cifs]
+      vfs_getattr_nosec+0x126/0x180
+      vfs_statx+0xf6/0x220
+      do_statx+0xab/0x110
+      __x64_sys_statx+0xd5/0x130
+      do_syscall_64+0xbb/0x380
+      entry_SYSCALL_64_after_hwframe+0x77/0x7f
+
+Fixes: f2aee329a68f ("cifs: set domainName when a domain-key is used in multiuser")
+Signed-off-by: Paulo Alcantara (Red Hat) <pc@manguebit.org>
+Reviewed-by: David Howells <dhowells@redhat.com>
+Cc: Jay Shin <jaeshin@redhat.com>
+Cc: stable@vger.kernel.org
+Cc: linux-cifs@vger.kernel.org
+Signed-off-by: Steve French <stfrench@microsoft.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/smb/client/connect.c |    1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/fs/smb/client/connect.c
++++ b/fs/smb/client/connect.c
+@@ -4224,6 +4224,7 @@ cifs_construct_tcon(struct cifs_sb_info
+ out:
+       kfree(ctx->username);
++      kfree(ctx->domainname);
+       kfree_sensitive(ctx->password);
+       kfree(origin_fullpath);
+       kfree(ctx);
diff --git a/queue-6.6/thunderbolt-add-support-for-intel-wildcat-lake.patch b/queue-6.6/thunderbolt-add-support-for-intel-wildcat-lake.patch
new file mode 100644 (file)
index 0000000..8a9b3bc
--- /dev/null
@@ -0,0 +1,43 @@
+From 3575254546a27210a4b661ea37fbbfb836c0815d Mon Sep 17 00:00:00 2001
+From: Alan Borzeszkowski <alan.borzeszkowski@linux.intel.com>
+Date: Thu, 14 Nov 2024 10:55:44 +0100
+Subject: thunderbolt: Add support for Intel Wildcat Lake
+
+From: Alan Borzeszkowski <alan.borzeszkowski@linux.intel.com>
+
+commit 3575254546a27210a4b661ea37fbbfb836c0815d upstream.
+
+Intel Wildcat Lake derives its Thunderbolt/USB4 controller from Lunar
+Lake platform. Add Wildcat Lake PCI ID to the driver list of supported
+devices.
+
+Signed-off-by: Alan Borzeszkowski <alan.borzeszkowski@linux.intel.com>
+Cc: stable@vger.kernel.org
+Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/thunderbolt/nhi.c |    2 ++
+ drivers/thunderbolt/nhi.h |    1 +
+ 2 files changed, 3 insertions(+)
+
+--- a/drivers/thunderbolt/nhi.c
++++ b/drivers/thunderbolt/nhi.c
+@@ -1536,6 +1536,8 @@ static struct pci_device_id nhi_ids[] =
+         .driver_data = (kernel_ulong_t)&icl_nhi_ops },
+       { PCI_VDEVICE(INTEL, PCI_DEVICE_ID_INTEL_PTL_P_NHI1),
+         .driver_data = (kernel_ulong_t)&icl_nhi_ops },
++      { PCI_VDEVICE(INTEL, PCI_DEVICE_ID_INTEL_WCL_NHI0),
++        .driver_data = (kernel_ulong_t)&icl_nhi_ops },
+       { PCI_VDEVICE(INTEL, PCI_DEVICE_ID_INTEL_BARLOW_RIDGE_HOST_80G_NHI) },
+       { PCI_VDEVICE(INTEL, PCI_DEVICE_ID_INTEL_BARLOW_RIDGE_HOST_40G_NHI) },
+--- a/drivers/thunderbolt/nhi.h
++++ b/drivers/thunderbolt/nhi.h
+@@ -75,6 +75,7 @@ extern const struct tb_nhi_ops icl_nhi_o
+ #define PCI_DEVICE_ID_INTEL_TITAN_RIDGE_DD_BRIDGE     0x15ef
+ #define PCI_DEVICE_ID_INTEL_ADL_NHI0                  0x463e
+ #define PCI_DEVICE_ID_INTEL_ADL_NHI1                  0x466d
++#define PCI_DEVICE_ID_INTEL_WCL_NHI0                  0x4d33
+ #define PCI_DEVICE_ID_INTEL_BARLOW_RIDGE_HOST_80G_NHI 0x5781
+ #define PCI_DEVICE_ID_INTEL_BARLOW_RIDGE_HOST_40G_NHI 0x5784
+ #define PCI_DEVICE_ID_INTEL_BARLOW_RIDGE_HUB_80G_BRIDGE 0x5786