--- /dev/null
+From 74570e12b4705ea11dcdfbfbd0a0b0fdaeff3059 Mon Sep 17 00:00:00 2001
+From: Gyeyoung Baek <gye976@gmail.com>
+Date: Sun, 19 Apr 2026 16:17:15 +0900
+Subject: accel/rocket: Fix prep_bo ioctl leaking positive return from dma_resv_wait_timeout()
+
+From: Gyeyoung Baek <gye976@gmail.com>
+
+commit 74570e12b4705ea11dcdfbfbd0a0b0fdaeff3059 upstream.
+
+dma_resv_wait_timeout() returns a positive 'remaining jiffies' value
+on success, 0 on timeout, and -errno on failure.
+
+rocket_ioctl_prep_bo() returns this 'long' result from an int-typed
+ioctl handler, so positive values reach userspace as bogus errors.
+Explicitly set ret to 0 on the success path.
+
+Fixes: 525ad89dd904 ("accel/rocket: Add IOCTLs for synchronizing memory accesses")
+Cc: stable@vger.kernel.org
+Signed-off-by: Gyeyoung Baek <gye976@gmail.com>
+Reviewed-by: Tomeu Vizoso <tomeu@tomeuvizoso.net>
+Link: https://patch.msgid.link/c0ebf83b345721701b22d8f5bc41c52c0ecf5e16.1776581974.git.gye976@gmail.com
+Signed-off-by: Steven Price <steven.price@arm.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/accel/rocket/rocket_gem.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/drivers/accel/rocket/rocket_gem.c
++++ b/drivers/accel/rocket/rocket_gem.c
+@@ -144,6 +144,8 @@ int rocket_ioctl_prep_bo(struct drm_devi
+ ret = dma_resv_wait_timeout(gem_obj->resv, DMA_RESV_USAGE_WRITE, true, timeout);
+ if (!ret)
+ ret = timeout ? -ETIMEDOUT : -EBUSY;
++ else if (ret > 0)
++ ret = 0;
+
+ shmem_obj = &to_rocket_bo(gem_obj)->base;
+
--- /dev/null
+From 7d1051ad68df3d584b5f24bfa1fb19f3a24db278 Mon Sep 17 00:00:00 2001
+From: Adrien Burnett <an.arctic.pigeon@gmail.com>
+Date: Thu, 14 May 2026 18:59:05 +0200
+Subject: ALSA: hda/realtek: Add mute LED quirk for HP Pavilion Laptop 16-ag0xxx
+
+From: Adrien Burnett <an.arctic.pigeon@gmail.com>
+
+commit 7d1051ad68df3d584b5f24bfa1fb19f3a24db278 upstream.
+
+Add a SND_PCI_QUIRK entry for the HP Pavilion Laptop 16-ag0xxx
+(subsystem 0x103c:0x8cbc, Realtek ALC245). The
+ALC245_FIXUP_HP_X360_MUTE_LEDS fixup is already used by the
+neighbouring HP Pavilion Aero Laptop 13-bg0xxx (0x103c:0x8cbd);
+it chains the master-mute COEF handler with the GPIO mic-mute
+LED handler, which is what this machine needs.
+
+Tested on the affected hardware: both the mute and mic-mute key
+LEDs respond correctly to the keyboard hotkeys after this change.
+
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Adrien Burnett <an.arctic.pigeon@gmail.com>
+Link: https://patch.msgid.link/20260514165905.21175-1-an.arctic.pigeon@gmail.com
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ sound/hda/codecs/realtek/alc269.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/sound/hda/codecs/realtek/alc269.c
++++ b/sound/hda/codecs/realtek/alc269.c
+@@ -6960,6 +6960,7 @@ static const struct hda_quirk alc269_fix
+ SND_PCI_QUIRK(0x103c, 0x8ca4, "HP ZBook Fury", ALC245_FIXUP_CS35L41_SPI_2_HP_GPIO_LED),
+ SND_PCI_QUIRK(0x103c, 0x8ca7, "HP ZBook Fury", ALC245_FIXUP_CS35L41_SPI_2_HP_GPIO_LED),
+ SND_PCI_QUIRK(0x103c, 0x8caf, "HP Elite mt645 G8 Mobile Thin Client", ALC236_FIXUP_HP_MUTE_LED_MICMUTE_VREF),
++ SND_PCI_QUIRK(0x103c, 0x8cbc, "HP Pavilion Laptop 16-ag0xxx", ALC245_FIXUP_HP_X360_MUTE_LEDS),
+ SND_PCI_QUIRK(0x103c, 0x8cbd, "HP Pavilion Aero Laptop 13-bg0xxx", ALC245_FIXUP_HP_X360_MUTE_LEDS),
+ SND_PCI_QUIRK(0x103c, 0x8cdd, "HP Spectre", ALC245_FIXUP_HP_SPECTRE_X360_EU0XXX),
+ SND_PCI_QUIRK(0x103c, 0x8cde, "HP OmniBook Ultra Flip Laptop 14t", ALC245_FIXUP_HP_SPECTRE_X360_EU0XXX),
--- /dev/null
+From fd87b510f5f543125ecf51e7c706a9f4bc3352be Mon Sep 17 00:00:00 2001
+From: Markus Kramer <linux@markus-kramer.de>
+Date: Thu, 14 May 2026 00:28:18 +0200
+Subject: ALSA: hda/realtek: Add quirk for Samsung Galaxy Book5 360 headphone
+
+From: Markus Kramer <linux@markus-kramer.de>
+
+commit fd87b510f5f543125ecf51e7c706a9f4bc3352be upstream.
+
+The Samsung Galaxy Book5 360 (NP750QHA, PCI subsystem ID 0x144d:0xc902)
+has severe audio distortion on the 3.5mm headphone jack. Applying
+ALC256_FIXUP_SAMSUNG_HEADPHONE_VERY_QUIET corrects the output path
+configuration, consistent with fixes already applied to other Samsung
+Galaxy Book models using the same ALC256 codec.
+
+Cc: stable@vger.kernel.org
+Link: https://github.com/thesofproject/linux/issues/5648
+Signed-off-by: Markus Kramer <linux@markus-kramer.de>
+Link: https://patch.msgid.link/20260513222818.14351-1-linux@markus-kramer.de
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ sound/hda/codecs/realtek/alc269.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/sound/hda/codecs/realtek/alc269.c
++++ b/sound/hda/codecs/realtek/alc269.c
+@@ -7240,6 +7240,7 @@ static const struct hda_quirk alc269_fix
+ SND_PCI_QUIRK(0x144d, 0xc870, "Samsung Galaxy Book2 Pro (NP950XED)", ALC298_FIXUP_SAMSUNG_AMP_V2_2_AMPS),
+ SND_PCI_QUIRK(0x144d, 0xc872, "Samsung Galaxy Book2 Pro (NP950XEE)", ALC298_FIXUP_SAMSUNG_AMP_V2_2_AMPS),
+ SND_PCI_QUIRK(0x144d, 0xc886, "Samsung Galaxy Book3 Pro (NP964XFG)", ALC298_FIXUP_SAMSUNG_AMP_V2_4_AMPS),
++ SND_PCI_QUIRK(0x144d, 0xc902, "Samsung Galaxy Book5 360 (NP750QHA)", ALC256_FIXUP_SAMSUNG_HEADPHONE_VERY_QUIET),
+ SND_PCI_QUIRK(0x144d, 0xc1ca, "Samsung Galaxy Book3 Pro 360 (NP960QFG)", ALC298_FIXUP_SAMSUNG_AMP_V2_4_AMPS),
+ SND_PCI_QUIRK(0x144d, 0xc1cb, "Samsung Galaxy Book3 Pro 360 (NP965QFG)", ALC298_FIXUP_SAMSUNG_AMP_V2_4_AMPS),
+ SND_PCI_QUIRK(0x144d, 0xc1cc, "Samsung Galaxy Book3 Ultra (NT960XFH)", ALC298_FIXUP_SAMSUNG_AMP_V2_4_AMPS),
--- /dev/null
+From 918be519c7876329e1b6e2ea1c59f0b75e792dca Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?C=C3=A1ssio=20Gabriel?= <cassiogabrielcontato@gmail.com>
+Date: Thu, 7 May 2026 00:40:52 -0300
+Subject: ALSA: usb-audio: Bound MIDI 2.0 endpoint descriptor scans
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Cássio Gabriel <cassiogabrielcontato@gmail.com>
+
+commit 918be519c7876329e1b6e2ea1c59f0b75e792dca upstream.
+
+The USB MIDI 2.0 endpoint parser has the same descriptor walking
+pattern as the legacy MIDI parser. It validates bLength against
+bNumGrpTrmBlock before reading baAssoGrpTrmBlkID[], but not against the
+remaining bytes in the endpoint-extra scan.
+
+A malformed device can therefore make later baAssoGrpTrmBlkID[] reads
+consume bytes past the walked descriptor.
+
+Reject zero-length and overlong descriptors while walking endpoint
+extras.
+
+Fixes: ff49d1df79ae ("ALSA: usb-audio: USB MIDI 2.0 UMP support")
+Cc: stable@vger.kernel.org
+Signed-off-by: Cássio Gabriel <cassiogabrielcontato@gmail.com>
+Link: https://patch.msgid.link/20260507-usb-midi-endpoint-scan-bounds-v1-2-329d7348160e@gmail.com
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ sound/usb/midi2.c | 12 +++++++-----
+ 1 file changed, 7 insertions(+), 5 deletions(-)
+
+--- a/sound/usb/midi2.c
++++ b/sound/usb/midi2.c
+@@ -496,15 +496,17 @@ static void *find_usb_ms_endpoint_descri
+ while (extralen > 3) {
+ struct usb_ms_endpoint_descriptor *ms_ep =
+ (struct usb_ms_endpoint_descriptor *)extra;
++ int length = ms_ep->bLength;
+
+- if (ms_ep->bLength > 3 &&
++ if (!length || length > extralen)
++ break;
++
++ if (length > 3 &&
+ ms_ep->bDescriptorType == USB_DT_CS_ENDPOINT &&
+ ms_ep->bDescriptorSubtype == subtype)
+ return ms_ep;
+- if (!extra[0])
+- break;
+- extralen -= extra[0];
+- extra += extra[0];
++ extralen -= length;
++ extra += length;
+ }
+ return NULL;
+ }
--- /dev/null
+From d6854daa67be623860f4e1873fd3d3c275aba4ed Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?C=C3=A1ssio=20Gabriel?= <cassiogabrielcontato@gmail.com>
+Date: Thu, 7 May 2026 00:40:51 -0300
+Subject: ALSA: usb-audio: Bound MIDI endpoint descriptor scans
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Cássio Gabriel <cassiogabrielcontato@gmail.com>
+
+commit d6854daa67be623860f4e1873fd3d3c275aba4ed upstream.
+
+snd_usbmidi_get_ms_info() validates the internal MIDIStreaming endpoint
+descriptor size before using baAssocJackID[], but the descriptor walker can
+still return a class-specific endpoint descriptor whose bLength exceeds the
+remaining bytes in the endpoint-extra scan.
+
+That leaves later flexible-array reads bounded by bLength, but not by the
+remaining bytes in the endpoint-extra scan.
+
+Stop walking when bLength is zero or
+extends past the remaining endpoint-extra scan.
+
+Fixes: 5c6cd7021a05 ("ALSA: usb-audio: Fix case when USB MIDI interface has more than one extra endpoint descriptor")
+Cc: stable@vger.kernel.org
+Signed-off-by: Cássio Gabriel <cassiogabrielcontato@gmail.com>
+Link: https://patch.msgid.link/20260507-usb-midi-endpoint-scan-bounds-v1-1-329d7348160e@gmail.com
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ sound/usb/midi.c | 12 +++++++-----
+ 1 file changed, 7 insertions(+), 5 deletions(-)
+
+--- a/sound/usb/midi.c
++++ b/sound/usb/midi.c
+@@ -1947,15 +1947,17 @@ static struct usb_ms_endpoint_descriptor
+ while (extralen > 3) {
+ struct usb_ms_endpoint_descriptor *ms_ep =
+ (struct usb_ms_endpoint_descriptor *)extra;
++ int length = ms_ep->bLength;
+
+- if (ms_ep->bLength > 3 &&
++ if (!length || length > extralen)
++ break;
++
++ if (length > 3 &&
+ ms_ep->bDescriptorType == USB_DT_CS_ENDPOINT &&
+ ms_ep->bDescriptorSubtype == UAC_MS_GENERAL)
+ return ms_ep;
+- if (!extra[0])
+- break;
+- extralen -= extra[0];
+- extra += extra[0];
++ extralen -= length;
++ extra += length;
+ }
+ return NULL;
+ }
--- /dev/null
+From 814b2c9b30e56074e11fc0a6e5419b3fee0639bc Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?C=C3=A1ssio=20Gabriel?= <cassiogabrielcontato@gmail.com>
+Date: Mon, 11 May 2026 01:36:37 -0300
+Subject: ALSA: usb-audio: qcom: Check offload mapping failures
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Cássio Gabriel <cassiogabrielcontato@gmail.com>
+
+commit 814b2c9b30e56074e11fc0a6e5419b3fee0639bc upstream.
+
+uaudio_transfer_buffer_setup() calls dma_get_sgtable() and then passes
+the sg_table to uaudio_iommu_map_xfer_buf() without checking whether sg
+table construction succeeded. If dma_get_sgtable() fails, the sg_table
+contents are not valid.
+
+uaudio_iommu_map_pa() also ignores iommu_map() failures for the event and
+transfer rings and still returns the allocated IOVA to the QMI response.
+That can expose an unmapped IOVA to the audio DSP. For transfer rings,
+the failed mapping also leaves the IOVA allocator state marked in use.
+
+Check both operations. Free the coherent transfer buffer when sg table
+construction fails, free the sg table when transfer-buffer IOMMU mapping
+fails, and release the transfer-ring IOVA if iommu_map() fails. Also
+return the existing event-ring IOVA when the event ring is already mapped,
+matching the pre-split helper behavior.
+
+Fixes: 326bbc348298 ("ALSA: usb-audio: qcom: Introduce QC USB SND offloading support")
+Fixes: 44499ecb4f28 ("ALSA: usb: qcom: Fix false-positive address space check")
+Cc: stable@vger.kernel.org
+Signed-off-by: Cássio Gabriel <cassiogabrielcontato@gmail.com>
+Link: https://patch.msgid.link/20260511-alsa-usb-qcom-offload-map-errors-v1-1-6502695e58bc@gmail.com
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ sound/usb/qcom/qc_audio_offload.c | 31 +++++++++++++++++++++++++------
+ 1 file changed, 25 insertions(+), 6 deletions(-)
+
+--- a/sound/usb/qcom/qc_audio_offload.c
++++ b/sound/usb/qcom/qc_audio_offload.c
+@@ -565,6 +565,7 @@ static unsigned long uaudio_iommu_map_pa
+ unsigned long iova = 0;
+ bool map = true;
+ int prot = uaudio_iommu_map_prot(dma_coherent);
++ int ret;
+
+ switch (mtype) {
+ case MEM_EVENT_RING:
+@@ -582,10 +583,24 @@ static unsigned long uaudio_iommu_map_pa
+ dev_err(uaudio_qdev->data->dev, "unknown mem type %d\n", mtype);
+ }
+
+- if (!iova || !map)
++ if (!iova)
+ return 0;
+
+- iommu_map(uaudio_qdev->data->domain, iova, pa, size, prot, GFP_KERNEL);
++ if (!map)
++ return iova;
++
++ ret = iommu_map(uaudio_qdev->data->domain, iova, pa, size, prot,
++ GFP_KERNEL);
++ if (ret) {
++ dev_err(uaudio_qdev->data->dev,
++ "failed to map %zu bytes at iova 0x%08lx: %d\n",
++ size, iova, ret);
++ if (mtype == MEM_XFER_RING)
++ uaudio_put_iova(iova, size,
++ &uaudio_qdev->xfer_ring_list,
++ &uaudio_qdev->xfer_ring_iova_size);
++ return 0;
++ }
+
+ return iova;
+ }
+@@ -1054,15 +1069,17 @@ static int uaudio_transfer_buffer_setup(
+ if (!xfer_buf)
+ return -ENOMEM;
+
+- dma_get_sgtable(subs->dev->bus->sysdev, &xfer_buf_sgt, xfer_buf,
+- xfer_buf_dma, len);
++ ret = dma_get_sgtable(subs->dev->bus->sysdev, &xfer_buf_sgt, xfer_buf,
++ xfer_buf_dma, len);
++ if (ret)
++ goto free_xfer_buf;
+
+ /* map the physical buffer into sysdev as well */
+ xfer_buf_dma_sysdev = uaudio_iommu_map_xfer_buf(dma_coherent,
+ len, &xfer_buf_sgt);
+ if (!xfer_buf_dma_sysdev) {
+ ret = -ENOMEM;
+- goto unmap_sync;
++ goto free_sgt;
+ }
+
+ mem_info->dma = xfer_buf_dma;
+@@ -1073,7 +1090,9 @@ static int uaudio_transfer_buffer_setup(
+
+ return 0;
+
+-unmap_sync:
++free_sgt:
++ sg_free_table(&xfer_buf_sgt);
++free_xfer_buf:
+ usb_free_coherent(subs->dev, len, xfer_buf, xfer_buf_dma);
+
+ return ret;
--- /dev/null
+From 4066c55e109475a06d18a1f127c939d551211956 Mon Sep 17 00:00:00 2001
+From: Qu Wenruo <wqu@suse.com>
+Date: Thu, 30 Apr 2026 10:37:22 +0930
+Subject: btrfs: only release the dirty pages io tree after successful writes
+
+From: Qu Wenruo <wqu@suse.com>
+
+commit 4066c55e109475a06d18a1f127c939d551211956 upstream.
+
+[WARNING]
+With extra warning on dirty extent buffers at umount (aka, the next
+patch in the series), test case generic/388 can trigger the following
+warning about dirty extent buffers at unmount time:
+
+ BTRFS critical (device dm-2 state E): emergency shutdown
+ BTRFS error (device dm-2 state E): error while writing out transaction: -30
+ BTRFS warning (device dm-2 state E): Skipping commit of aborted transaction.
+ BTRFS error (device dm-2 state EA): Transaction 9 aborted (error -30)
+ BTRFS: error (device dm-2 state EA) in cleanup_transaction:2068: errno=-30 Readonly filesystem
+ BTRFS info (device dm-2 state EA): forced readonly
+ BTRFS info (device dm-2 state EA): last unmount of filesystem 4fbf2e15-f941-49a0-bc7c-716315d2777c
+ ------------[ cut here ]------------
+ WARNING: disk-io.c:3311 at invalidate_and_check_btree_folios+0xfd/0x1ca [btrfs], CPU#8: umount/914368
+ CPU: 8 UID: 0 PID: 914368 Comm: umount Tainted: G OE 7.1.0-rc1-custom+ #372 PREEMPT(full) 2de38db8d1deae71fde295430a0ff3ab98ccf596
+ Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS unknown 02/02/2022
+ RIP: 0010:invalidate_and_check_btree_folios+0xfd/0x1ca [btrfs]
+ Call Trace:
+ <TASK>
+ close_ctree+0x52e/0x574 [btrfs d2f0b1cd330d1287e7a9919d112eadfc0e914efd]
+ generic_shutdown_super+0x89/0x1a0
+ kill_anon_super+0x16/0x40
+ btrfs_kill_super+0x16/0x20 [btrfs d2f0b1cd330d1287e7a9919d112eadfc0e914efd]
+ deactivate_locked_super+0x2d/0xb0
+ cleanup_mnt+0xdc/0x140
+ task_work_run+0x5a/0xa0
+ exit_to_user_mode_loop+0x123/0x4b0
+ do_syscall_64+0x243/0x7c0
+ entry_SYSCALL_64_after_hwframe+0x4b/0x53
+ </TASK>
+ ---[ end trace 0000000000000000 ]---
+ BTRFS warning (device dm-2 state EA): unable to release extent buffer 30539776 owner 9 gen 9 refs 2 flags 0x7
+ BTRFS warning (device dm-2 state EA): unable to release extent buffer 30621696 owner 257 gen 9 refs 2 flags 0x7
+ BTRFS warning (device dm-2 state EA): unable to release extent buffer 30638080 owner 258 gen 9 refs 2 flags 0x7
+ BTRFS warning (device dm-2 state EA): unable to release extent buffer 30654464 owner 7 gen 9 refs 2 flags 0x7
+ BTRFS warning (device dm-2 state EA): unable to release extent buffer 30703616 owner 2 gen 9 refs 2 flags 0x7
+ BTRFS warning (device dm-2 state EA): unable to release extent buffer 30720000 owner 10 gen 9 refs 2 flags 0x7
+ BTRFS warning (device dm-2 state EA): unable to release extent buffer 30736384 owner 4 gen 9 refs 2 flags 0x7
+ BTRFS warning (device dm-2 state EA): unable to release extent buffer 30752768 owner 11 gen 9 refs 2 flags 0x7
+
+I'm using a stripped down version, which seems to trigger the warning
+more reliably:
+
+ _fsstress_pid=""
+ workload()
+ {
+ dmesg -C
+ mkfs.btrfs -f -K $dev > /dev/null
+ echo 1 > /sys/kernel/debug/clear_warn_once
+ mount $dev $mnt
+ $fsstress -w -n 1024 -p 4 -d $mnt &
+ _fsstress_pid=$!
+ sleep 0
+ $godown $mnt
+ pkill --echo -PIPE fsstress > /dev/null
+ wait $_fsstress_pid
+ unset _fsstress_pid
+ umount $mnt
+
+ if dmesg | grep -q "WARNING"; then
+ fail
+ fi
+ }
+
+ for (( i = 0; i < $runtime; i++ )); do
+ echo "=== $i/$runtime ==="
+ workload
+ done
+
+[CAUSE]
+Inside btrfs_write_and_wait_transaction(), we first try to write all
+dirty ebs, then wait for them to finish.
+
+After that we call btrfs_extent_io_tree_release() to free all
+extent states from dirty_pages io tree.
+
+However if we hit an error from btrfs_write_marked_extent(), then we
+still call btrfs_extent_io_tree_release() to clear that dirty_pages io
+tree, which may contain dirty records that we haven't yet submitted.
+
+Furthermore, the later transaction cleanup path will utilize that
+dirty_pages io tree to properly cleanup those dirty ebs, but since it's
+already empty, no dirty ebs are properly cleaned up, thus will later
+trigger the warnings inside invalidate_btree_folios().
+
+[FIX]
+Normally such dirty ebs won't cause problems, as when the iput() is
+called on the btree inode, the dirty ebs will be forcibly written back,
+and since the fs is already in an error status, such writeback will not
+reach disk and finish immediately.
+
+But it's still better to get rid of such dirty ebs, if we ended up with
+dirty ebs but the fs is not in an error status, then such writeback at
+iput() time will be too late, as all workers are already stopped but
+writeback will utilize workers, which will lead to NULL pointer
+dereferences.
+
+Instead of unconditionally calling btrfs_extent_io_tree_release(), only
+call it if btrfs_write_and_wait_transaction() finished successfully, so
+that @dirty_pages extent io tree is kept untouched for transaction
+cleanup.
+
+CC: stable@vger.kernel.org # 6.1+
+Reviewed-by: Filipe Manana <fdmanana@suse.com>
+Signed-off-by: Qu Wenruo <wqu@suse.com>
+Signed-off-by: David Sterba <dsterba@suse.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/btrfs/disk-io.c | 1 +
+ fs/btrfs/transaction.c | 9 ++++-----
+ 2 files changed, 5 insertions(+), 5 deletions(-)
+
+--- a/fs/btrfs/disk-io.c
++++ b/fs/btrfs/disk-io.c
+@@ -4646,6 +4646,7 @@ static void btrfs_destroy_marked_extents
+ free_extent_buffer_stale(eb);
+ }
+ }
++ btrfs_extent_io_tree_release(dirty_pages);
+ }
+
+ static void btrfs_destroy_pinned_extent(struct btrfs_fs_info *fs_info,
+--- a/fs/btrfs/transaction.c
++++ b/fs/btrfs/transaction.c
+@@ -1268,14 +1268,13 @@ static int btrfs_write_and_wait_transact
+ blk_finish_plug(&plug);
+ ret2 = btrfs_wait_extents(fs_info, dirty_pages);
+
+- btrfs_extent_io_tree_release(&trans->transaction->dirty_pages);
+-
+ if (ret)
+ return ret;
+- else if (ret2)
++ if (ret2)
+ return ret2;
+- else
+- return 0;
++
++ btrfs_extent_io_tree_release(&trans->transaction->dirty_pages);
++ return 0;
+ }
+
+ /*
--- /dev/null
+From 5d3cc36b4e77a27ce7b686b7c59c7072bcb3fa8e Mon Sep 17 00:00:00 2001
+From: Viacheslav Dubeyko <Slava.Dubeyko@ibm.com>
+Date: Thu, 9 Apr 2026 12:26:02 -0700
+Subject: ceph: fix a buffer leak in __ceph_setxattr()
+
+From: Viacheslav Dubeyko <Slava.Dubeyko@ibm.com>
+
+commit 5d3cc36b4e77a27ce7b686b7c59c7072bcb3fa8e upstream.
+
+The old_blob in __ceph_setxattr() can store
+ci->i_xattrs.prealloc_blob value during the retry.
+However, it is never called the ceph_buffer_put()
+for the old_blob object. This patch fixes the issue of
+the buffer leak.
+
+Cc: stable@vger.kernel.org
+Signed-off-by: Viacheslav Dubeyko <Slava.Dubeyko@ibm.com>
+Reviewed-by: Alex Markuze <amarkuze@redhat.com>
+Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/ceph/xattr.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/fs/ceph/xattr.c
++++ b/fs/ceph/xattr.c
+@@ -1296,6 +1296,7 @@ retry:
+
+ do_sync:
+ spin_unlock(&ci->i_ceph_lock);
++ ceph_buffer_put(old_blob);
+ do_sync_unlocked:
+ if (lock_snap_rwsem)
+ up_read(&mdsc->snap_rwsem);
--- /dev/null
+From 0c22d9511cbde746622f8e4c11aaa63fe76d45f9 Mon Sep 17 00:00:00 2001
+From: Viacheslav Dubeyko <Slava.Dubeyko@ibm.com>
+Date: Thu, 9 Apr 2026 12:43:40 -0700
+Subject: ceph: fix BUG_ON in __ceph_build_xattrs_blob() due to stale blob size
+
+From: Viacheslav Dubeyko <Slava.Dubeyko@ibm.com>
+
+commit 0c22d9511cbde746622f8e4c11aaa63fe76d45f9 upstream.
+
+The generic/642 test-case can reproduce the kernel crash:
+
+[40243.605254] ------------[ cut here ]------------
+[40243.605956] kernel BUG at fs/ceph/xattr.c:918!
+[40243.607142] Oops: invalid opcode: 0000 [#1] SMP PTI
+[40243.608067] CPU: 7 UID: 0 PID: 498762 Comm: kworker/7:1 Not tainted 7.0.0-rc7+ #3 PREEMPT(full)
+[40243.609700] Hardware name: QEMU Ubuntu 25.10 PC v2 (i440FX + PIIX, + 10.1 machine, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
+[40243.611820] Workqueue: ceph-msgr ceph_con_workfn
+[40243.612715] RIP: 0010:__ceph_build_xattrs_blob+0x1b8/0x1e0
+[40243.613731] Code: 0f 84 82 fe ff ff e9 cf 8e 56 ff 48 8d 65 e8 31 c0 5b 41 5c 41 5d 5d 31 d2 31 c9 31 f6 31 ff 45 31 c0 45 31 c9 c3 cc cc cc cc <0f> 0b 4c 8b 62 08 41 8b 85 24 07 00 00 49 83 c4 04 41 89 44 24 fc
+[40243.616888] RSP: 0018:ffffcc80c4d4b688 EFLAGS: 00010287
+[40243.617773] RAX: 0000000000010026 RBX: 0000000000000001 RCX: 0000000000000000
+[40243.618928] RDX: ffff8a773798dee0 RSI: 0000000000000000 RDI: 0000000000000000
+[40243.620158] RBP: ffffcc80c4d4b6a0 R08: 0000000000000000 R09: 0000000000000000
+[40243.621573] R10: 0000000000000000 R11: 0000000000000000 R12: ffff8a75f3b58000
+[40243.622907] R13: ffff8a75f3b58000 R14: 0000000000000080 R15: 000000000000bffd
+[40243.624054] FS: 0000000000000000(0000) GS:ffff8a787d1b4000(0000) knlGS:0000000000000000
+[40243.625331] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
+[40243.626269] CR2: 000072f390b623c0 CR3: 000000011c02a003 CR4: 0000000000372ef0
+[40243.627408] Call Trace:
+[40243.627839] <TASK>
+[40243.628188] __prep_cap+0x3fd/0x4a0
+[40243.628789] ? do_raw_spin_unlock+0x4e/0xe0
+[40243.629474] ceph_check_caps+0x46a/0xc80
+[40243.630094] ? __lock_acquire+0x4a2/0x2650
+[40243.630773] ? find_held_lock+0x31/0x90
+[40243.631347] ? handle_cap_grant+0x79f/0x1060
+[40243.632068] ? lock_release+0xd9/0x300
+[40243.632696] ? __mutex_unlock_slowpath+0x3e/0x340
+[40243.633429] ? lock_release+0xd9/0x300
+[40243.634052] handle_cap_grant+0xcf6/0x1060
+[40243.634745] ceph_handle_caps+0x122b/0x2110
+[40243.635415] mds_dispatch+0x5bd/0x2160
+[40243.636034] ? ceph_con_process_message+0x65/0x190
+[40243.636828] ? lock_release+0xd9/0x300
+[40243.637431] ceph_con_process_message+0x7a/0x190
+[40243.638184] ? kfree+0x311/0x4f0
+[40243.638749] ? kfree+0x311/0x4f0
+[40243.639268] process_message+0x16/0x1a0
+[40243.639915] ? sg_free_table+0x39/0x90
+[40243.640572] ceph_con_v2_try_read+0xf58/0x2120
+[40243.641255] ? lock_acquire+0xc8/0x300
+[40243.641863] ceph_con_workfn+0x151/0x820
+[40243.642493] process_one_work+0x22f/0x630
+[40243.643093] ? process_one_work+0x254/0x630
+[40243.643770] worker_thread+0x1e2/0x400
+[40243.644332] ? __pfx_worker_thread+0x10/0x10
+[40243.645020] kthread+0x109/0x140
+[40243.645560] ? __pfx_kthread+0x10/0x10
+[40243.646125] ret_from_fork+0x3f8/0x480
+[40243.646752] ? __pfx_kthread+0x10/0x10
+[40243.647316] ? __pfx_kthread+0x10/0x10
+[40243.647919] ret_from_fork_asm+0x1a/0x30
+[40243.648556] </TASK>
+[40243.648902] Modules linked in: overlay hctr2 libpolyval chacha libchacha adiantum libnh libpoly1305 essiv intel_rapl_msr intel_rapl_common intel_uncore_frequency_common skx_edac_common nfit kvm_intel kvm irqbypass joydev ghash_clmulni_intel aesni_intel rapl input_leds mac_hid psmouse vga16fb serio_raw vgastate floppy i2c_piix4 pata_acpi bochs qemu_fw_cfg i2c_smbus sch_fq_codel rbd dm_crypt msr parport_pc ppdev lp parport efi_pstore
+[40243.654766] ---[ end trace 0000000000000000 ]---
+
+Commit d93231a6bc8a ("ceph: prevent a client from exceeding the MDS
+maximum xattr size") moved the required_blob_size computation to before
+the __build_xattrs() call, introducing a race.
+
+__build_xattrs() releases and reacquires i_ceph_lock during execution.
+In that window, handle_cap_grant() may update i_xattrs.blob with a
+newer MDS-provided blob and bump i_xattrs.version. When
+__build_xattrs() detects that index_version < version, it destroys and
+rebuilds the entire xattr rb-tree from the new blob, potentially
+increasing count, names_size, and vals_size.
+
+The prealloc_blob size check that follows still uses the stale
+required_blob_size computed before the rebuild, so it passes even when
+prealloc_blob is too small for the now-larger tree. After __set_xattr()
+adds one more xattr on top, __ceph_build_xattrs_blob() is called from
+the cap flush path and hits:
+
+ BUG_ON(need > ci->i_xattrs.prealloc_blob->alloc_len);
+
+Fix this by recomputing required_blob_size after __build_xattrs()
+returns, using the current tree state. Also re-validate against
+m_max_xattr_size to fall back to the sync path if the rebuilt tree now
+exceeds the MDS limit.
+
+Cc: stable@vger.kernel.org
+Fixes: d93231a6bc8a ("ceph: prevent a client from exceeding the MDS maximum xattr size")
+Signed-off-by: Viacheslav Dubeyko <Slava.Dubeyko@ibm.com>
+Reviewed-by: Alex Markuze <amarkuze@redhat.com>
+Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/ceph/xattr.c | 16 ++++++++++++++++
+ 1 file changed, 16 insertions(+)
+
+--- a/fs/ceph/xattr.c
++++ b/fs/ceph/xattr.c
+@@ -1256,6 +1256,22 @@ retry:
+ ceph_vinop(inode), name, ceph_cap_string(issued));
+ __build_xattrs(inode);
+
++ /*
++ * __build_xattrs() may have released and reacquired i_ceph_lock,
++ * during which handle_cap_grant() could have replaced i_xattrs.blob
++ * with a newer MDS-provided blob and bumped i_xattrs.version. If that
++ * caused __build_xattrs() to rebuild the rb-tree from the new blob,
++ * count/names_size/vals_size may now be larger than when
++ * required_blob_size was computed above. Recompute it here so the
++ * prealloc_blob size check below reflects the current tree state.
++ */
++ required_blob_size = __get_required_blob_size(ci, name_len, val_len);
++ if (required_blob_size > mdsc->mdsmap->m_max_xattr_size) {
++ doutc(cl, "sync (size too large): %d > %llu\n",
++ required_blob_size, mdsc->mdsmap->m_max_xattr_size);
++ goto do_sync;
++ }
++
+ if (!ci->i_xattrs.prealloc_blob ||
+ required_blob_size > ci->i_xattrs.prealloc_blob->alloc_len) {
+ struct ceph_buffer *blob;
--- /dev/null
+From 1ae15b6c7965d137eef21f2cc7d367b29cb88369 Mon Sep 17 00:00:00 2001
+From: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com>
+Date: Tue, 5 May 2026 14:39:20 +0530
+Subject: drm/i915/dp: Fix VSC dynamic range signaling for RGB formats
+
+From: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com>
+
+commit 1ae15b6c7965d137eef21f2cc7d367b29cb88369 upstream.
+
+For RGB, set dynamic_range to CTA or VESA based on
+crtc_state->limited_color_range so sinks apply correct
+quantization. YCbCr remains limited (CTA) range.
+(DP v1.4, Table 5-1)
+
+v2:
+- Added Reported-by and Tested-by tags
+
+v3:
+- Add back YCbCr comment(Suraj)
+
+Cc: stable@vger.kernel.org #v5.8+
+Reported-by: DeepChirp <DeepChirp@outlook.com>
+Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/work_items/15874
+Tested-by: DeepChirp <DeepChirp@outlook.com>
+Fixes: 9799c4c3b76e ("drm/i915/dp: Add compute routine for DP VSC SDP")
+Assisted-by: GitHub-Copilot:GPT-5.4
+Signed-off-by: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com>
+Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
+Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
+Link: https://patch.msgid.link/20260505090920.2479112-1-chaitanya.kumar.borah@intel.com
+(cherry picked from commit 38e10ddae6f8d42a2e8437fcd25a1cac51106c64)
+Signed-off-by: Tvrtko Ursulin <tursulin@ursulin.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/i915/display/intel_dp.c | 9 +++++++--
+ 1 file changed, 7 insertions(+), 2 deletions(-)
+
+--- a/drivers/gpu/drm/i915/display/intel_dp.c
++++ b/drivers/gpu/drm/i915/display/intel_dp.c
+@@ -2869,8 +2869,13 @@ static void intel_dp_compute_vsc_colorim
+ drm_WARN_ON(display->drm,
+ vsc->bpc == 6 && vsc->pixelformat != DP_PIXELFORMAT_RGB);
+
+- /* all YCbCr are always limited range */
+- vsc->dynamic_range = DP_DYNAMIC_RANGE_CTA;
++ /* All YCbCr formats are always limited range. */
++ if (vsc->pixelformat == DP_PIXELFORMAT_RGB)
++ vsc->dynamic_range = crtc_state->limited_color_range ?
++ DP_DYNAMIC_RANGE_CTA : DP_DYNAMIC_RANGE_VESA;
++ else
++ vsc->dynamic_range = DP_DYNAMIC_RANGE_CTA;
++
+ vsc->content_type = DP_CONTENT_TYPE_NOT_DEFINED;
+ }
+
--- /dev/null
+From 4cfe4c0efbdcde742a47813180cc69b132d7598e Mon Sep 17 00:00:00 2001
+From: Sebastian Brzezinka <sebastian.brzezinka@intel.com>
+Date: Thu, 16 Apr 2026 13:31:18 +0200
+Subject: drm/i915: skip __i915_request_skip() for already signaled requests
+
+From: Sebastian Brzezinka <sebastian.brzezinka@intel.com>
+
+commit 4cfe4c0efbdcde742a47813180cc69b132d7598e upstream.
+
+After a GPU reset the HWSP is zeroed, so previously completed
+requests appear incomplete. If such a request is picked up during
+reset_rewind() and marked guilty, i915_request_set_error_once()
+returns early (fence already signaled), leaving fence.error without
+a fatal error code. The subsequent __i915_request_skip() then hits:
+```
+GEM_BUG_ON(!fatal_error(rq->fence.error))
+```
+
+Fixes a kernel BUG observed on Sandy Bridge (Gen6) during
+heartbeat-triggered engine resets.
+```
+kernel BUG at drivers/gpu/drm/i915/i915_request.c:556!
+RIP: __i915_request_skip+0x15e/0x1d0 [i915]
+...
+__i915_request_reset+0x212/0xa70 [i915]
+reset_rewind+0xe4/0x280 [i915]
+intel_gt_reset+0x30d/0x5b0 [i915]
+heartbeat+0x516/0x530 [i915]
+```
+
+Guard __i915_request_skip() with i915_request_signaled(), if the
+fence is already signaled, the ring content is committed and there
+is nothing left to skip.
+
+Fixes: 36e191f0644b ("drm/i915: Apply i915_request_skip() on submission")
+Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/work_items/13729
+Signed-off-by: Sebastian Brzezinka <sebastian.brzezinka@intel.com>
+Cc: stable@vger.kernel.org # v5.7+
+Reviewed-by: Krzysztof Karas <krzysztof.karas@intel.com>
+Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com>
+Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com>
+Link: https://lore.kernel.org/r/fe76921d35b6ae85aa651822726d0d9815aa5362.1776339012.git.sebastian.brzezinka@intel.com
+(cherry picked from commit 5ba54393dcd7adf75a9f39f5a933b1538349cad5)
+Signed-off-by: Tvrtko Ursulin <tursulin@ursulin.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/i915/gt/intel_reset.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/drivers/gpu/drm/i915/gt/intel_reset.c
++++ b/drivers/gpu/drm/i915/gt/intel_reset.c
+@@ -132,7 +132,8 @@ void __i915_request_reset(struct i915_re
+ rcu_read_lock(); /* protect the GEM context */
+ if (guilty) {
+ i915_request_set_error_once(rq, -EIO);
+- __i915_request_skip(rq);
++ if (!i915_request_signaled(rq))
++ __i915_request_skip(rq);
+ banned = mark_guilty(rq);
+ } else {
+ i915_request_set_error_once(rq, -EAGAIN);
--- /dev/null
+From 0a9c56dd387605d17dabeedd9fdd2c4c1d0bab7b Mon Sep 17 00:00:00 2001
+From: Myeonghun Pak <mhun512@gmail.com>
+Date: Wed, 13 May 2026 15:57:00 +0900
+Subject: drm/loongson: Use managed KMS polling
+
+From: Myeonghun Pak <mhun512@gmail.com>
+
+commit 0a9c56dd387605d17dabeedd9fdd2c4c1d0bab7b upstream.
+
+lsdc_pci_probe() initializes KMS polling before setting up vblank support,
+requesting the IRQ and registering the DRM device. If any of those later
+steps fails, probe returns without finalizing polling. The driver also
+never finalizes polling on regular removal.
+
+Use drmm_kms_helper_poll_init() so polling is tied to the DRM device
+lifetime and automatically finalized on probe failure and device removal.
+
+This issue was identified during our ongoing static-analysis research while
+reviewing kernel code.
+
+Fixes: f39db26c5428 ("drm: Add kms driver for loongson display controller")
+Cc: stable@vger.kernel.org
+Co-developed-by: Ijae Kim <ae878000@gmail.com>
+Signed-off-by: Ijae Kim <ae878000@gmail.com>
+Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
+Acked-by: Jianmin Lv <lvjianmin@loongson.cn>
+Reviewed-by: Huacai Chen <chenhuacai@loongson.cn>
+Signed-off-by: Myeonghun Pak <mhun512@gmail.com>
+Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
+Link: https://patch.msgid.link/20260513065706.23803-1-mhun512@gmail.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/loongson/lsdc_drv.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/gpu/drm/loongson/lsdc_drv.c
++++ b/drivers/gpu/drm/loongson/lsdc_drv.c
+@@ -291,7 +291,7 @@ static int lsdc_pci_probe(struct pci_dev
+
+ vga_client_register(pdev, lsdc_vga_set_decode);
+
+- drm_kms_helper_poll_init(ddev);
++ drmm_kms_helper_poll_init(ddev);
+
+ if (loongson_vblank) {
+ ret = drm_vblank_init(ddev, descp->num_of_crtc);
--- /dev/null
+From 459d75523b71c0ec254d153d8850d0b7008af396 Mon Sep 17 00:00:00 2001
+From: Gyeyoung Baek <gye976@gmail.com>
+Date: Sun, 19 Apr 2026 16:17:16 +0900
+Subject: drm/panfrost: Fix wait_bo ioctl leaking positive return from dma_resv_wait_timeout()
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Gyeyoung Baek <gye976@gmail.com>
+
+commit 459d75523b71c0ec254d153d8850d0b7008af396 upstream.
+
+dma_resv_wait_timeout() returns a positive 'remaining jiffies' value
+on success, 0 on timeout, and -errno on failure.
+
+panfrost_ioctl_wait_bo() returns this 'long' result from an int-typed
+ioctl handler, so positive values reach userspace as bogus errors.
+Explicitly set ret to 0 on the success path.
+
+Fixes: f3ba91228e8e ("drm/panfrost: Add initial panfrost driver")
+Cc: stable@vger.kernel.org
+Signed-off-by: Gyeyoung Baek <gye976@gmail.com>
+Reviewed-by: Adrián Larumbe <adrian.larumbe@collabora.com>
+Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
+Reviewed-by: Steven Price <steven.price@arm.com>
+Link: https://patch.msgid.link/fe33f82fded7be1c18e2e0eb2db451d5a738cf39.1776581974.git.gye976@gmail.com
+Signed-off-by: Steven Price <steven.price@arm.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/panfrost/panfrost_drv.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/drivers/gpu/drm/panfrost/panfrost_drv.c
++++ b/drivers/gpu/drm/panfrost/panfrost_drv.c
+@@ -365,6 +365,8 @@ panfrost_ioctl_wait_bo(struct drm_device
+ true, timeout);
+ if (!ret)
+ ret = timeout ? -ETIMEDOUT : -EBUSY;
++ else if (ret > 0)
++ ret = 0;
+
+ drm_gem_object_put(gem_obj);
+
--- /dev/null
+From dc366607c41c45fd0ae6f3db090f31dd611b644a Mon Sep 17 00:00:00 2001
+From: Edward Adam Davis <eadavis@qq.com>
+Date: Wed, 13 May 2026 12:30:50 +0800
+Subject: drm: Replace old pointer to new idr
+
+From: Edward Adam Davis <eadavis@qq.com>
+
+commit dc366607c41c45fd0ae6f3db090f31dd611b644a upstream.
+
+Commit 5e28b7b94408 introduced a logical error by failing to replace the
+newly generated IDR pointer to old id's pointer at the correct location
+within the "change handle" logic; this resulted in the issue reported by
+syzbot [1].
+
+Specifically, the new IDR object pointer is intended to replace the original
+id's pointer during the normal execution flow.
+
+Additionally, an unnecessary conditional check for the ret exit path has
+been removed.
+
+[1]
+!RB_EMPTY_ROOT(&prime_fpriv->dmabufs)
+WARNING: drivers/gpu/drm/drm_prime.c:224 at drm_prime_destroy_file_private+0x48/0x60 drivers/gpu/drm/drm_prime.c:224, CPU#0: syz.0.17/5833
+Call Trace:
+ drm_file_free.part.0+0x7e6/0xcc0 drivers/gpu/drm/drm_file.c:269
+ drm_file_free drivers/gpu/drm/drm_file.c:237 [inline]
+ drm_close_helper.isra.0+0x186/0x200 drivers/gpu/drm/drm_file.c:290
+ drm_release+0x1ab/0x360 drivers/gpu/drm/drm_file.c:438
+
+Fixes: 5e28b7b94408 ("drm: Set old handle to NULL before prime swap in change_handle")
+Reported-by: syzbot+d7c9eed171647e421013@syzkaller.appspotmail.com
+Closes: https://syzkaller.appspot.com/bug?extid=d7c9eed171647e421013
+Cc: stable@vger.kernel.org
+Tested-by: syzbot+d7c9eed171647e421013@syzkaller.appspotmail.com
+Signed-off-by: Edward Adam Davis <eadavis@qq.com>
+Signed-off-by: Dave Airlie <airlied@redhat.com>
+Link: https://patch.msgid.link/tencent_C267296443AAA4567771176886DFF364A305@qq.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/drm_gem.c | 7 ++-----
+ 1 file changed, 2 insertions(+), 5 deletions(-)
+
+--- a/drivers/gpu/drm/drm_gem.c
++++ b/drivers/gpu/drm/drm_gem.c
+@@ -1017,17 +1017,12 @@ int drm_gem_change_handle_ioctl(struct d
+
+ spin_unlock(&file_priv->table_lock);
+
+- if (ret < 0)
+- goto out_unlock;
+-
+ if (obj->dma_buf) {
+ ret = drm_prime_add_buf_handle(&file_priv->prime, obj->dma_buf,
+ handle);
+ if (ret < 0) {
+ spin_lock(&file_priv->table_lock);
+ idr_remove(&file_priv->object_idr, handle);
+- idrobj = idr_replace(&file_priv->object_idr, obj, handle);
+- WARN_ON(idrobj != NULL);
+ spin_unlock(&file_priv->table_lock);
+ goto out_unlock;
+ }
+@@ -1039,7 +1034,9 @@ int drm_gem_change_handle_ioctl(struct d
+
+ spin_lock(&file_priv->table_lock);
+ idr_remove(&file_priv->object_idr, args->handle);
++ idrobj = idr_replace(&file_priv->object_idr, obj, handle);
+ spin_unlock(&file_priv->table_lock);
++ WARN_ON(idrobj != NULL);
+
+ out_unlock:
+ mutex_unlock(&file_priv->prime.lock);
--- /dev/null
+From 591711b32681a04b57d00c2a404658f8419a081c Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Thomas=20Hellstr=C3=B6m?= <thomas.hellstrom@linux.intel.com>
+Date: Fri, 8 May 2026 18:09:20 +0200
+Subject: drm/ttm: Convert -EAGAIN from dmem_cgroup_try_charge to -ENOSPC
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Thomas Hellström <thomas.hellstrom@linux.intel.com>
+
+commit 591711b32681a04b57d00c2a404658f8419a081c upstream.
+
+dmem_cgroup_try_charge() returns -EAGAIN when the cgroup limit is
+hit and the charge fails. TTM has no concept of -EAGAIN from resource
+allocation; -ENOSPC is the canonical error meaning "no space, try
+eviction". Convert at the source in ttm_resource_alloc() so no caller
+needs to handle an unexpected error code, and clean up the now-redundant
+-EAGAIN check in ttm_bo_alloc_resource().
+
+Without this, -EAGAIN escaping ttm_resource_alloc() during an eviction
+walk causes the walk to terminate early instead of continuing to the
+next candidate.
+
+Cc: Friedrich Vock <friedrich.vock@gmx.de>
+Cc: Maarten Lankhorst <dev@lankhorst.se>
+Cc: Tejun Heo <tj@kernel.org>
+Cc: Maxime Ripard <mripard@kernel.org>
+Cc: Christian Koenig <christian.koenig@amd.com>
+Cc: dri-devel@lists.freedesktop.org
+Cc: <stable@vger.kernel.org> # v6.14+
+Fixes: 2b624a2c1865 ("drm/ttm: Handle cgroup based eviction in TTM")
+Assisted-by: GitHub_Copilot:claude-sonnet-4.6
+Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
+Reviewed-by: Maarten Lankhorst <dev@lankhrost.se>
+Link: https://patch.msgid.link/20260508160920.230339-1-thomas.hellstrom@linux.intel.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/ttm/ttm_bo.c | 2 +-
+ drivers/gpu/drm/ttm/ttm_resource.c | 5 ++++-
+ 2 files changed, 5 insertions(+), 2 deletions(-)
+
+--- a/drivers/gpu/drm/ttm/ttm_bo.c
++++ b/drivers/gpu/drm/ttm/ttm_bo.c
+@@ -739,7 +739,7 @@ static int ttm_bo_alloc_resource(struct
+ may_evict = (force_space && place->mem_type != TTM_PL_SYSTEM);
+ ret = ttm_resource_alloc(bo, place, res, force_space ? &limit_pool : NULL);
+ if (ret) {
+- if (ret != -ENOSPC && ret != -EAGAIN) {
++ if (ret != -ENOSPC) {
+ dmem_cgroup_pool_state_put(limit_pool);
+ return ret;
+ }
+--- a/drivers/gpu/drm/ttm/ttm_resource.c
++++ b/drivers/gpu/drm/ttm/ttm_resource.c
+@@ -384,8 +384,11 @@ int ttm_resource_alloc(struct ttm_buffer
+
+ if (man->cg) {
+ ret = dmem_cgroup_try_charge(man->cg, bo->base.size, &pool, ret_limit_pool);
+- if (ret)
++ if (ret) {
++ if (ret == -EAGAIN)
++ ret = -ENOSPC;
+ return ret;
++ }
+ }
+
+ ret = man->func->alloc(man, bo, place, res_ptr);
--- /dev/null
+From 155a372a1cc50fa93387c5d3cdfd614a61e1afd1 Mon Sep 17 00:00:00 2001
+From: Matthew Auld <matthew.auld@intel.com>
+Date: Fri, 8 May 2026 11:26:37 +0100
+Subject: drm/xe/dma-buf: fix UAF with retry loop
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Matthew Auld <matthew.auld@intel.com>
+
+commit 155a372a1cc50fa93387c5d3cdfd614a61e1afd1 upstream.
+
+Retry doesn't work here, since bo will be freed on error, leading to
+UAF. However, now that we do the alloc & init before the attach, we can
+now combine this as one unit and have the init do the alloc for us. This
+should make the retry safe.
+
+Reported by Sashiko.
+
+v2: Fix up the error unwind (CI)
+
+Closes: https://sashiko.dev/#/patchset/20260506184332.86743-2-matthew.auld%40intel.com
+Fixes: eb289a5f6cc6 ("drm/xe: Convert xe_dma_buf.c for exhaustive eviction")
+Signed-off-by: Matthew Auld <matthew.auld@intel.com>
+Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
+Cc: Matthew Brost <matthew.brost@intel.com>
+Cc: <stable@vger.kernel.org> # v6.18+
+Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
+Link: https://patch.msgid.link/20260508102635.149172-4-matthew.auld@intel.com
+(cherry picked from commit 479669418253e0f27f8cf5db01a731352ea592e7)
+Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/xe/xe_dma_buf.c | 49 +++++++++-------------------------------
+ 1 file changed, 12 insertions(+), 37 deletions(-)
+
+--- a/drivers/gpu/drm/xe/xe_dma_buf.c
++++ b/drivers/gpu/drm/xe/xe_dma_buf.c
+@@ -227,16 +227,8 @@ struct dma_buf *xe_gem_prime_export(stru
+ return buf;
+ }
+
+-/*
+- * Takes ownership of @storage: on success it is transferred to the returned
+- * drm_gem_object; on failure it is freed before returning the error.
+- * This matches the contract of xe_bo_init_locked() which frees @storage on
+- * its error paths, so callers need not (and must not) free @storage after
+- * this call.
+- */
+ static struct drm_gem_object *
+-xe_dma_buf_init_obj(struct drm_device *dev, struct xe_bo *storage,
+- struct dma_buf *dma_buf)
++xe_dma_buf_create_obj(struct drm_device *dev, struct dma_buf *dma_buf)
+ {
+ struct dma_resv *resv = dma_buf->resv;
+ struct xe_device *xe = to_xe_device(dev);
+@@ -247,10 +239,8 @@ xe_dma_buf_init_obj(struct drm_device *d
+ int ret = 0;
+
+ dummy_obj = drm_gpuvm_resv_object_alloc(&xe->drm);
+- if (!dummy_obj) {
+- xe_bo_free(storage);
++ if (!dummy_obj)
+ return ERR_PTR(-ENOMEM);
+- }
+
+ dummy_obj->resv = resv;
+ xe_validation_guard(&ctx, &xe->val, &exec, (struct xe_val_flags) {}, ret) {
+@@ -259,8 +249,7 @@ xe_dma_buf_init_obj(struct drm_device *d
+ if (ret)
+ break;
+
+- /* xe_bo_init_locked() frees storage on error */
+- bo = xe_bo_init_locked(xe, storage, NULL, resv, NULL, dma_buf->size,
++ bo = xe_bo_init_locked(xe, NULL, NULL, resv, NULL, dma_buf->size,
+ 0, /* Will require 1way or 2way for vm_bind */
+ ttm_bo_type_sg, XE_BO_FLAG_SYSTEM, &exec);
+ drm_exec_retry_on_contention(&exec);
+@@ -311,7 +300,6 @@ struct drm_gem_object *xe_gem_prime_impo
+ const struct dma_buf_attach_ops *attach_ops;
+ struct dma_buf_attachment *attach;
+ struct drm_gem_object *obj;
+- struct xe_bo *bo;
+
+ if (dma_buf->ops == &xe_dmabuf_ops) {
+ obj = dma_buf->priv;
+@@ -326,22 +314,14 @@ struct drm_gem_object *xe_gem_prime_impo
+ }
+ }
+
+- bo = xe_bo_alloc();
+- if (IS_ERR(bo))
+- return ERR_CAST(bo);
+-
+ /*
+- * xe_dma_buf_init_obj() takes ownership of the raw bo, so do not touch
+- * on fail, since it will already take care of cleanup. On success we
+- * still need to drop the ref, if something later fails.
+- *
+- * In addition this needs to happen before the attach, since
+- * it will create a new attachment for this, and add it to the list of
+- * attachments, at which point it is globally visible, and at any point
+- * the export side can call into on invalidate_mappings callback, which
+- * require a working object.
++ * This needs to happen before the attach, since it will create a new
++ * attachment for this, and add it to the list of attachments, at which
++ * point it is globally visible, and at any point the export side can
++ * call into on invalidate_mappings callback, which require a working
++ * object.
+ */
+- obj = xe_dma_buf_init_obj(dev, bo, dma_buf);
++ obj = xe_dma_buf_create_obj(dev, dma_buf);
+ if (IS_ERR(obj))
+ return obj;
+
+@@ -351,20 +331,15 @@ struct drm_gem_object *xe_gem_prime_impo
+ attach_ops = test->attach_ops;
+ #endif
+
+- attach = dma_buf_dynamic_attach(dma_buf, dev->dev, attach_ops, &bo->ttm.base);
++ attach = dma_buf_dynamic_attach(dma_buf, dev->dev, attach_ops, obj);
+ if (IS_ERR(attach)) {
+- obj = ERR_CAST(attach);
+- goto out_err;
++ xe_bo_put(gem_to_xe_bo(obj));
++ return ERR_CAST(attach);
+ }
+
+ get_dma_buf(dma_buf);
+ obj->import_attach = attach;
+ return obj;
+-
+-out_err:
+- xe_bo_put(bo);
+-
+- return obj;
+ }
+
+ #if IS_ENABLED(CONFIG_DRM_XE_KUNIT_TEST)
--- /dev/null
+From 981bedbbe61364fcc3a3b87ebaf648a66cd07108 Mon Sep 17 00:00:00 2001
+From: Matthew Auld <matthew.auld@intel.com>
+Date: Fri, 8 May 2026 11:26:36 +0100
+Subject: drm/xe/dma-buf: handle empty bo and UAF races
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Matthew Auld <matthew.auld@intel.com>
+
+commit 981bedbbe61364fcc3a3b87ebaf648a66cd07108 upstream.
+
+There look to be some nasty races here when triggering the
+invalidate_mappings hook:
+
+1) We do xe_bo_alloc() followed by the attach, before the actual full bo
+ init step in xe_dma_buf_init_obj(). However the bo is visible on the
+ attachments list after the attach. This is bad since exporter driver,
+ say amdgpu, can at any time call back into our invalidate_mappings hook,
+ with an empty/bogus bo, leading to potential bugs/crashes.
+
+2) Similar to 1) but here we get a UAF, when the invalidate_mappings
+ hook is triggered. For example, we get as far as xe_bo_init_locked()
+ but this fails in some way. But here the bo will be freed on error, but
+ we still have it attached from dma-buf pov, so if the
+ invalidate_mappings is now triggered then the bo we access is gone and
+ we trigger UAF and more bugs/crashes.
+
+To fix this, move the attach step until after we actually have a fully
+set up buffer object. Note that the bo is not published to userspace
+until later, so not sure what the comment "Don't publish the bo
+until we have a valid attachment", is referring to.
+
+We have at least two different customers reporting hitting a NULL ptr
+deref in evict_flags when importing something from amdgpu, followed by
+triggering the evict flow. Hit rate is also pretty low, which would
+hint at some kind of race, so something like 1) or 2) might explain
+this.
+
+v2:
+ - Shuffle the order of the ops slightly (no functional change)
+ - Improve the comment to better explain the ordering (Matt B)
+
+Assisted-by: Gemini:gemini-3 #debug
+Link: https://gitlab.freedesktop.org/drm/xe/kernel/-/work_items/7903
+Link: https://gitlab.freedesktop.org/drm/xe/kernel/-/work_items/4055
+Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs")
+Signed-off-by: Matthew Auld <matthew.auld@intel.com>
+Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
+Cc: Matthew Brost <matthew.brost@intel.com>
+Cc: <stable@vger.kernel.org> # v6.8+
+Reviewed-by: Matthew Brost <matthew.brost@intel.com>
+Acked-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
+Link: https://patch.msgid.link/20260508102635.149172-3-matthew.auld@intel.com
+(cherry picked from commit af1f2ad0c59fe4e2f924c526f66e968289d77971)
+Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/xe/xe_dma_buf.c | 31 ++++++++++++++++---------------
+ 1 file changed, 16 insertions(+), 15 deletions(-)
+
+--- a/drivers/gpu/drm/xe/xe_dma_buf.c
++++ b/drivers/gpu/drm/xe/xe_dma_buf.c
+@@ -326,15 +326,25 @@ struct drm_gem_object *xe_gem_prime_impo
+ }
+ }
+
+- /*
+- * Don't publish the bo until we have a valid attachment, and a
+- * valid attachment needs the bo address. So pre-create a bo before
+- * creating the attachment and publish.
+- */
+ bo = xe_bo_alloc();
+ if (IS_ERR(bo))
+ return ERR_CAST(bo);
+
++ /*
++ * xe_dma_buf_init_obj() takes ownership of the raw bo, so do not touch
++ * on fail, since it will already take care of cleanup. On success we
++ * still need to drop the ref, if something later fails.
++ *
++ * In addition this needs to happen before the attach, since
++ * it will create a new attachment for this, and add it to the list of
++ * attachments, at which point it is globally visible, and at any point
++ * the export side can call into on invalidate_mappings callback, which
++ * require a working object.
++ */
++ obj = xe_dma_buf_init_obj(dev, bo, dma_buf);
++ if (IS_ERR(obj))
++ return obj;
++
+ attach_ops = &xe_dma_buf_attach_ops;
+ #if IS_ENABLED(CONFIG_DRM_XE_KUNIT_TEST)
+ if (test)
+@@ -347,21 +357,12 @@ struct drm_gem_object *xe_gem_prime_impo
+ goto out_err;
+ }
+
+- /*
+- * xe_dma_buf_init_obj() takes ownership of bo on both success
+- * and failure, so we must not touch bo after this call.
+- */
+- obj = xe_dma_buf_init_obj(dev, bo, dma_buf);
+- if (IS_ERR(obj)) {
+- dma_buf_detach(dma_buf, attach);
+- return obj;
+- }
+ get_dma_buf(dma_buf);
+ obj->import_attach = attach;
+ return obj;
+
+ out_err:
+- xe_bo_free(bo);
++ xe_bo_put(bo);
+
+ return obj;
+ }
--- /dev/null
+From d6a2d7b04b5a093021a7a0e2e69e9d5237dfa8cc Mon Sep 17 00:00:00 2001
+From: Nicholas Carlini <nicholas@carlini.com>
+Date: Mon, 11 May 2026 18:02:16 +0000
+Subject: io-wq: check that the predecessor is hashed in io_wq_remove_pending()
+
+From: Nicholas Carlini <nicholas@carlini.com>
+
+commit d6a2d7b04b5a093021a7a0e2e69e9d5237dfa8cc upstream.
+
+io_wq_remove_pending() needs to fix up wq->hash_tail[] if the cancelled
+work was the tail of its hash bucket. When doing this, it checks whether
+the preceding entry in acct->work_list has the same hash value, but
+never checks that the predecessor is hashed at all. io_get_work_hash()
+is simply atomic_read(&work->flags) >> IO_WQ_HASH_SHIFT, and the hash
+bits are never set for non-hashed work, so it returns 0. Thus, when a
+hashed bucket-0 work is cancelled while a non-hashed work is its list
+predecessor, the check spuriously passes and a pointer to the non-hashed
+io_kiocb is stored in wq->hash_tail[0].
+
+Because non-hashed work is dequeued via the fast path in
+io_get_next_work(), which never touches hash_tail[], the stale pointer
+is never cleared. Therefore, after the non-hashed io_kiocb completes and
+is freed back to req_cachep, wq->hash_tail[0] is a dangling pointer. The
+io_wq is per-task (tctx->io_wq) and survives ring open/close, so the
+dangling pointer persists for the lifetime of the task; the next hashed
+bucket-0 enqueue dereferences it in io_wq_insert_work() and
+wq_list_add_after() writes through freed memory.
+
+Add the missing io_wq_is_hashed() check so a non-hashed predecessor
+never inherits a hash_tail[] slot.
+
+Cc: stable@vger.kernel.org
+Fixes: 204361a77f40 ("io-wq: fix hang after cancelling pending hashed work")
+Signed-off-by: Nicholas Carlini <nicholas@carlini.com>
+Signed-off-by: Jens Axboe <axboe@kernel.dk>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ io_uring/io-wq.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/io_uring/io-wq.c
++++ b/io_uring/io-wq.c
+@@ -1125,7 +1125,8 @@ static inline void io_wq_remove_pending(
+ if (io_wq_is_hashed(work) && work == wq->hash_tail[hash]) {
+ if (prev)
+ prev_work = container_of(prev, struct io_wq_work, list);
+- if (prev_work && io_get_work_hash(prev_work) == hash)
++ if (prev_work && io_wq_is_hashed(prev_work) &&
++ io_get_work_hash(prev_work) == hash)
+ wq->hash_tail[hash] = prev_work;
+ else
+ wq->hash_tail[hash] = NULL;
--- /dev/null
+From 07d0f496fe7ec5abe3bee7e38be709521567bb33 Mon Sep 17 00:00:00 2001
+From: "Jose Fernandez (Anthropic)" <jose.fernandez@linux.dev>
+Date: Tue, 21 Apr 2026 19:26:13 +0000
+Subject: iommu/amd: Bounds-check devid in __rlookup_amd_iommu()
+
+From: Jose Fernandez (Anthropic) <jose.fernandez@linux.dev>
+
+commit 07d0f496fe7ec5abe3bee7e38be709521567bb33 upstream.
+
+iommu_device_register() walks every device on the PCI bus via
+bus_for_each_dev() and calls amd_iommu_probe_device() for each. The
+inlined check_device() path computes the device's sbdf, calls
+rlookup_amd_iommu() to find the owning IOMMU, and only afterwards
+verifies devid <= pci_seg->last_bdf. __rlookup_amd_iommu() indexes
+rlookup_table[devid] with no bounds check of its own, so for a PCI
+device whose BDF is not described by the IVRS, the lookup reads past
+the end of the allocation before the caller's bounds check can run.
+
+This was harmless before commit e874c666b15b ("iommu/amd: Change
+rlookup, irq_lookup, and alias to use kvalloc()"): the table was a
+zeroed page-order allocation, so the over-read returned NULL and the
+caller's NULL check skipped the device. After that commit the table is
+a tight kvcalloc() and the over-read returns adjacent slab contents,
+which check_device() then dereferences as a struct amd_iommu *,
+causing a boot-time GPF.
+
+Seen on Google Compute Engine ct6e VMs, where the virtualized IVRS
+describes only the four TPU endpoints 00:04.0-07.0; the gVNIC at
+00:08.0 (devid 0x40) indexes 56 bytes past the 456-byte allocation,
+into the adjacent kmalloc-512 slab object:
+
+ pci 0000:00:04.0: Adding to iommu group 0
+ pci 0000:00:05.0: Adding to iommu group 1
+ pci 0000:00:06.0: Adding to iommu group 2
+ pci 0000:00:07.0: Adding to iommu group 3
+ Oops: general protection fault, probably for non-canonical address 0x3a64695f78746382: 0000 [#1] SMP NOPTI
+ CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.18.22 #1
+ Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 12/06/2025
+ RIP: 0010:amd_iommu_probe_device+0x54/0x3a0
+ Call Trace:
+ __iommu_probe_device+0x107/0x520
+ probe_iommu_group+0x29/0x50
+ bus_for_each_dev+0x7e/0xe0
+ iommu_device_register+0xc9/0x240
+ iommu_go_to_state+0x9c0/0x1c60
+ amd_iommu_init+0x14/0x40
+ pci_iommu_init+0x16/0x60
+ do_one_initcall+0x47/0x2f0
+
+Guard the array access in __rlookup_amd_iommu(). With the fix applied
+on 6.18.22, the gVNIC at 00:08.0 is skipped cleanly and the VM boots.
+
+Fixes: e874c666b15b ("iommu/amd: Change rlookup, irq_lookup, and alias to use kvalloc()")
+Cc: stable@vger.kernel.org
+Reported-by: Ziyuan Chen <zc@anthropic.com>
+Tested-by: Ziyuan Chen <zc@anthropic.com>
+Reviewed-by: Josef Bacik <josef@toxicpanda.com>
+Assisted-by: Claude:unspecified
+Signed-off-by: Jose Fernandez (Anthropic) <jose.fernandez@linux.dev>
+Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/iommu/amd/iommu.c | 8 ++++++--
+ 1 file changed, 6 insertions(+), 2 deletions(-)
+
+--- a/drivers/iommu/amd/iommu.c
++++ b/drivers/iommu/amd/iommu.c
+@@ -329,8 +329,12 @@ static struct amd_iommu *__rlookup_amd_i
+ struct amd_iommu_pci_seg *pci_seg;
+
+ for_each_pci_segment(pci_seg) {
+- if (pci_seg->id == seg)
+- return pci_seg->rlookup_table[devid];
++ if (pci_seg->id != seg)
++ continue;
++ /* IVRS may not describe every device on the bus */
++ if (devid > pci_seg->last_bdf)
++ return NULL;
++ return pci_seg->rlookup_table[devid];
+ }
+ return NULL;
+ }
--- /dev/null
+From 79ea2feb917b05366b49d85573c9c5331f043b2c Mon Sep 17 00:00:00 2001
+From: Zhenzhong Duan <zhenzhong.duan@intel.com>
+Date: Sat, 9 May 2026 10:43:46 +0800
+Subject: iommu/vt-d: Avoid NULL pointer dereference or refcount corruption
+
+From: Zhenzhong Duan <zhenzhong.duan@intel.com>
+
+commit 79ea2feb917b05366b49d85573c9c5331f043b2c upstream.
+
+Commit 60f030f7418d ("iommu/vt-d: Avoid use of NULL after WARN_ON_ONCE")
+fixed a NULL pointer dereference in an unlikely situation partly.
+
+If dev_pasid is not found in the dev_pasids list, it remains NULL.
+However, the teardown operations are executed unconditionally, this lead
+to a NULL pointer dereference or refcount corruption.
+
+If the domain was never attached to this IOMMU, info will be NULL, which
+would cause an immediate dereference when checking --info->refcnt.
+
+Even if info is not NULL, decrementing the refcount without having removed
+a valid PASID might unbalance the count. This could lead to premature
+dropping of the refcount to 0, potentially causing a use-after-free for the
+remaining active devices sharing the domain.
+
+Fix it by returning early if dev_pasid is NULL, before executing the
+teardown operations.
+
+Issue found by AI review and suggested by Kevin Tian.
+https://sashiko.dev/#/patchset/20260421031347.1408890-1-zhenzhong.duan%40intel.com
+
+Fixes: 60f030f7418d ("iommu/vt-d: Avoid use of NULL after WARN_ON_ONCE")
+Cc: stable@vger.kernel.org
+Suggested-by: Kevin Tian <kevin.tian@intel.com>
+Signed-off-by: Zhenzhong Duan <zhenzhong.duan@intel.com>
+Reviewed-by: Kevin Tian <kevin.tian@intel.com>
+Link: https://lore.kernel.org/r/20260422033538.95000-1-zhenzhong.duan@intel.com
+Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>
+Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/iommu/intel/iommu.c | 9 +++++----
+ 1 file changed, 5 insertions(+), 4 deletions(-)
+
+--- a/drivers/iommu/intel/iommu.c
++++ b/drivers/iommu/intel/iommu.c
+@@ -4083,12 +4083,13 @@ void domain_remove_dev_pasid(struct iomm
+ }
+ spin_unlock_irqrestore(&dmar_domain->lock, flags);
+
++ if (WARN_ON_ONCE(!dev_pasid))
++ return;
++
+ cache_tag_unassign_domain(dmar_domain, dev, pasid);
+ domain_detach_iommu(dmar_domain, iommu);
+- if (!WARN_ON_ONCE(!dev_pasid)) {
+- intel_iommu_debugfs_remove_dev_pasid(dev_pasid);
+- kfree(dev_pasid);
+- }
++ intel_iommu_debugfs_remove_dev_pasid(dev_pasid);
++ kfree(dev_pasid);
+ }
+
+ static int blocking_domain_set_dev_pasid(struct iommu_domain *domain,
--- /dev/null
+From 2cda2e10dc8343ae01eae9e999a876b7e7d37861 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Naval=20Alcal=C3=A1?= <ari@naval.cat>
+Date: Sat, 9 May 2026 10:43:44 +0800
+Subject: iommu/vt-d: Disable DMAR for Intel Q35 IGFX
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Naval Alcalá <ari@naval.cat>
+
+commit 2cda2e10dc8343ae01eae9e999a876b7e7d37861 upstream.
+
+Intel Q35 integrated graphics (8086:29b2) exhibits broken DMAR
+behaviour similar to other G4x/GM45 devices for which DMAR is
+already disabled via quirks.
+
+When DMAR is enabled, the system may hard lock up during boot or
+early device initialization, requiring a reset.
+
+Add the missing PCI ID to the existing quirk list to disable
+DMAR for this device.
+
+Fixes: 1f76249cc3be ("iommu/vt-d: Declare Broadwell igfx dmar support snafu")
+Cc: stable@vger.kernel.org
+Closes: https://bugzilla.kernel.org/show_bug.cgi?id=201185
+Closes: https://bugzilla.kernel.org/show_bug.cgi?id=216064
+Signed-off-by: Naval Alcalá <ari@naval.cat>
+Link: https://lore.kernel.org/r/20260410161622.13549-1-ari@naval.cat
+Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>
+Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/iommu/intel/iommu.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/drivers/iommu/intel/iommu.c
++++ b/drivers/iommu/intel/iommu.c
+@@ -4517,6 +4517,9 @@ static void quirk_iommu_igfx(struct pci_
+ disable_igfx_iommu = 1;
+ }
+
++/* Q35 integrated gfx dmar support is totally busted. */
++DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x29b2, quirk_iommu_igfx);
++
+ /* G4x/GM45 integrated gfx dmar support is totally busted. */
+ DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x2a40, quirk_iommu_igfx);
+ DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x2e00, quirk_iommu_igfx);
--- /dev/null
+From a6dea58d8625c06b9654c0555f101742481335c3 Mon Sep 17 00:00:00 2001
+From: Zhenzhong Duan <zhenzhong.duan@intel.com>
+Date: Sat, 9 May 2026 10:43:45 +0800
+Subject: iommu/vt-d: Fix oops due to out of scope access
+
+From: Zhenzhong Duan <zhenzhong.duan@intel.com>
+
+commit a6dea58d8625c06b9654c0555f101742481335c3 upstream.
+
+Below oops triggers when kill QEMU process:
+
+ Oops: general protection fault, probably for non-canonical address 0x7fffffff844eaaa7: 0000 [#1] SMP NOPTI
+ Call Trace:
+ <TASK>
+ do_raw_spin_lock+0xaa/0xc0
+ _raw_spin_lock_irqsave+0x21/0x40
+ domain_remove_dev_pasid+0x52/0x160
+ intel_nested_set_dev_pasid+0x1b9/0x1e0
+ __iommu_set_group_pasid+0x56/0x120
+ pci_dev_reset_iommu_done+0xe3/0x180
+ pcie_flr+0x65/0x160
+ __pci_reset_function_locked+0x5b/0x120
+ vfio_pci_core_close_device+0x63/0xe0 [vfio_pci_core]
+ vfio_df_close+0x4f/0xa0
+ vfio_df_unbind_iommufd+0x2d/0x60
+ vfio_device_fops_release+0x3e/0x40
+ __fput+0xe5/0x2c0
+ task_work_run+0x58/0xa0
+ do_exit+0x2c8/0x600
+ do_group_exit+0x2f/0xa0
+ get_signal+0x863/0x8c0
+ arch_do_signal_or_restart+0x24/0x100
+ exit_to_user_mode_loop+0x87/0x380
+ do_syscall_64+0x2ff/0x11e0
+ entry_SYSCALL_64_after_hwframe+0x76/0x7e
+
+The global static blocked domain is a dummy domain without corresponding
+dmar_domain structure, accessing beyond iommu_domain structure triggers
+oops easily. Fix it by return early in domain_remove_dev_pasid() like
+identity domain.
+
+Fixes: 7d0c9da6c150 ("iommu/vt-d: Add set_dev_pasid callback for dma domain")
+Cc: stable@vger.kernel.org
+Signed-off-by: Zhenzhong Duan <zhenzhong.duan@intel.com>
+Reviewed-by: Kevin Tian <kevin.tian@intel.com>
+Link: https://lore.kernel.org/r/20260421031347.1408890-1-zhenzhong.duan@intel.com
+Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>
+Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/iommu/intel/iommu.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/drivers/iommu/intel/iommu.c
++++ b/drivers/iommu/intel/iommu.c
+@@ -4068,8 +4068,8 @@ void domain_remove_dev_pasid(struct iomm
+ if (!domain)
+ return;
+
+- /* Identity domain has no meta data for pasid. */
+- if (domain->type == IOMMU_DOMAIN_IDENTITY)
++ /* Identity domain and blocked domain have no meta data for pasid. */
++ if (domain->type == IOMMU_DOMAIN_IDENTITY || domain->type == IOMMU_DOMAIN_BLOCKED)
+ return;
+
+ dmar_domain = to_dmar_domain(domain);
--- /dev/null
+From a7c7e42654b6a8676610ee09d22901432c4851af Mon Sep 17 00:00:00 2001
+From: Sascha Bischoff <Sascha.Bischoff@arm.com>
+Date: Wed, 6 May 2026 09:37:43 +0000
+Subject: irqchip/gic-v5: Allocate ITS parent LPIs as a range
+
+From: Sascha Bischoff <Sascha.Bischoff@arm.com>
+
+commit a7c7e42654b6a8676610ee09d22901432c4851af upstream.
+
+The ITS MSI domain no longer manages LPI allocation directly. LPIs are
+allocated and freed by the parent LPI domain, which can now handle a
+full range of interrupts and unwind partial allocations internally.
+
+Make the ITS domain request and release the parent IRQs as a single
+range instead of iterating over each interrupt. The ITS allocation
+path then only needs to reserve EventIDs, allocate the parent range,
+and fill in the ITS irq_data for each MSI. Since no operation in the
+per-MSI loop can fail, the partial parent-free unwind becomes
+unnecessary.
+
+On teardown, reset the ITS irq_data for the range and then release the
+parent range in one call, leaving LPI teardown to the LPI domain.
+
+Fixes: 0f0101325876 ("irqchip/gic-v5: Add GICv5 LPI/IPI support")
+Signed-off-by: Sascha Bischoff <sascha.bischoff@arm.com>
+Signed-off-by: Thomas Gleixner <tglx@kernel.org>
+Reviewed-by: Marc Zyngier <maz@kernel.org>
+Reviewed-by: Lorenzo Pieralisi <lpieralisi@kernel.org>
+Cc: stable@vger.kernel.org
+Link: https://patch.msgid.link/20260506093634.382062-4-sascha.bischoff@arm.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/irqchip/irq-gic-v5-its.c | 22 +++++++---------------
+ 1 file changed, 7 insertions(+), 15 deletions(-)
+
+--- a/drivers/irqchip/irq-gic-v5-its.c
++++ b/drivers/irqchip/irq-gic-v5-its.c
+@@ -935,6 +935,7 @@ static int gicv5_its_irq_domain_alloc(st
+ int ret, i;
+
+ its_dev = info->scratchpad[0].ptr;
++ device_id = its_dev->device_id;
+
+ ret = gicv5_its_alloc_eventid(its_dev, info, nr_irqs, &event_id_base);
+ if (ret)
+@@ -944,14 +945,11 @@ static int gicv5_its_irq_domain_alloc(st
+ if (ret)
+ goto out_eventid;
+
+- device_id = its_dev->device_id;
++ ret = irq_domain_alloc_irqs_parent(domain, virq, nr_irqs, NULL);
++ if (ret)
++ goto out_eventid;
+
+ for (i = 0; i < nr_irqs; i++) {
+- ret = irq_domain_alloc_irqs_parent(domain, virq + i, 1, NULL);
+- if (ret) {
+- goto out_free_irqs;
+- }
+-
+ /*
+ * Store eventid and deviceid into the hwirq for later use.
+ *
+@@ -970,12 +968,6 @@ static int gicv5_its_irq_domain_alloc(st
+
+ return 0;
+
+-out_free_irqs:
+- while (--i >= 0) {
+- irqd = irq_domain_get_irq_data(domain, virq + i);
+- irq_domain_reset_irq_data(irqd);
+- irq_domain_free_irqs_parent(domain, virq + i, 1);
+- }
+ out_eventid:
+ gicv5_its_free_eventid(its_dev, event_id_base, nr_irqs);
+ return ret;
+@@ -998,14 +990,14 @@ static void gicv5_its_irq_domain_free(st
+ bitmap_release_region(its_dev->event_map, event_id_base,
+ get_count_order(nr_irqs));
+
+- /* Hierarchically free irq data */
+ for (i = 0; i < nr_irqs; i++) {
+ d = irq_domain_get_irq_data(domain, virq + i);
+-
+ irq_domain_reset_irq_data(d);
+- irq_domain_free_irqs_parent(domain, virq + i, 1);
+ }
+
++ /* Hierarchically free irq data */
++ irq_domain_free_irqs_parent(domain, virq, nr_irqs);
++
+ gicv5_its_syncr(its, its_dev);
+ gicv5_irs_syncr();
+ }
--- /dev/null
+From dec85d2fbd20de3711a71e65397dfdb40c3fa953 Mon Sep 17 00:00:00 2001
+From: Sascha Bischoff <Sascha.Bischoff@arm.com>
+Date: Wed, 6 May 2026 09:37:02 +0000
+Subject: irqchip/gic-v5: Move LPI allocation into the LPI domain
+
+From: Sascha Bischoff <Sascha.Bischoff@arm.com>
+
+commit dec85d2fbd20de3711a71e65397dfdb40c3fa953 upstream.
+
+The IPI and ITS MSI domains currently allocate and release LPIs
+directly, then pass the selected LPI ID to the parent LPI domain. This
+leaks the LPI domain's allocation policy into its child domains and
+forces each child to duplicate part of the parent domain's teardown.
+
+Make the LPI domain allocate LPIs in its .alloc() callback and release
+them in a matching .free() callback. Child domains can then request a
+parent interrupt without passing an implementation-specific LPI ID,
+and the LPI lifetime is tied to the domain that owns the LPI
+namespace.
+
+Remove the gicv5_alloc_lpi() and gicv5_free_lpi() wrappers now that no
+external caller needs to manage LPIs directly.
+
+This is a preparatory change for an actual leakage problem in the
+allocation code and therefore tagged with the same Fixes tag.
+
+Fixes: 0f0101325876 ("irqchip/gic-v5: Add GICv5 LPI/IPI support")
+Signed-off-by: Sascha Bischoff <sascha.bischoff@arm.com>
+Signed-off-by: Thomas Gleixner <tglx@kernel.org>
+Reviewed-by: Marc Zyngier <maz@kernel.org>
+Reviewed-by: Lorenzo Pieralisi <lpieralisi@kernel.org>
+Cc: stable@vger.kernel.org
+Link: https://patch.msgid.link/20260506093634.382062-2-sascha.bischoff@arm.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/irqchip/irq-gic-v5-its.c | 14 +--------
+ drivers/irqchip/irq-gic-v5.c | 53 ++++++++++++++++++-------------------
+ include/linux/irqchip/arm-gic-v5.h | 3 --
+ 3 files changed, 28 insertions(+), 42 deletions(-)
+
+--- a/drivers/irqchip/irq-gic-v5-its.c
++++ b/drivers/irqchip/irq-gic-v5-its.c
+@@ -927,8 +927,8 @@ static void gicv5_its_free_eventid(struc
+ static int gicv5_its_irq_domain_alloc(struct irq_domain *domain, unsigned int virq,
+ unsigned int nr_irqs, void *arg)
+ {
+- u32 device_id, event_id_base, lpi;
+ struct gicv5_its_dev *its_dev;
++ u32 device_id, event_id_base;
+ msi_alloc_info_t *info = arg;
+ irq_hw_number_t hwirq;
+ struct irq_data *irqd;
+@@ -947,16 +947,8 @@ static int gicv5_its_irq_domain_alloc(st
+ device_id = its_dev->device_id;
+
+ for (i = 0; i < nr_irqs; i++) {
+- ret = gicv5_alloc_lpi();
+- if (ret < 0) {
+- pr_debug("Failed to find free LPI!\n");
+- goto out_free_irqs;
+- }
+- lpi = ret;
+-
+- ret = irq_domain_alloc_irqs_parent(domain, virq + i, 1, &lpi);
++ ret = irq_domain_alloc_irqs_parent(domain, virq + i, 1, NULL);
+ if (ret) {
+- gicv5_free_lpi(lpi);
+ goto out_free_irqs;
+ }
+
+@@ -981,7 +973,6 @@ static int gicv5_its_irq_domain_alloc(st
+ out_free_irqs:
+ while (--i >= 0) {
+ irqd = irq_domain_get_irq_data(domain, virq + i);
+- gicv5_free_lpi(irqd->parent_data->hwirq);
+ irq_domain_reset_irq_data(irqd);
+ irq_domain_free_irqs_parent(domain, virq + i, 1);
+ }
+@@ -1011,7 +1002,6 @@ static void gicv5_its_irq_domain_free(st
+ for (i = 0; i < nr_irqs; i++) {
+ d = irq_domain_get_irq_data(domain, virq + i);
+
+- gicv5_free_lpi(d->parent_data->hwirq);
+ irq_domain_reset_irq_data(d);
+ irq_domain_free_irqs_parent(domain, virq + i, 1);
+ }
+--- a/drivers/irqchip/irq-gic-v5.c
++++ b/drivers/irqchip/irq-gic-v5.c
+@@ -58,16 +58,6 @@ static void release_lpi(u32 lpi)
+ ida_free(&lpi_ida, lpi);
+ }
+
+-int gicv5_alloc_lpi(void)
+-{
+- return alloc_lpi();
+-}
+-
+-void gicv5_free_lpi(u32 lpi)
+-{
+- release_lpi(lpi);
+-}
+-
+ static void gicv5_ppi_priority_init(void)
+ {
+ write_sysreg_s(REPEAT_BYTE(GICV5_IRQ_PRI_MI), SYS_ICC_PPI_PRIORITYR0_EL1);
+@@ -751,18 +741,36 @@ static void gicv5_lpi_config_reset(struc
+ gicv5_lpi_irq_write_pending_state(d, false);
+ }
+
++static void gicv5_irq_lpi_domain_free(struct irq_domain *domain, unsigned int virq,
++ unsigned int nr_irqs)
++{
++ struct irq_data *d;
++
++ if (WARN_ON_ONCE(nr_irqs != 1))
++ return;
++
++ d = irq_domain_get_irq_data(domain, virq);
++
++ release_lpi(d->hwirq);
++
++ irq_set_handler(virq, NULL);
++ irq_domain_reset_irq_data(d);
++}
++
+ static int gicv5_irq_lpi_domain_alloc(struct irq_domain *domain, unsigned int virq,
+ unsigned int nr_irqs, void *arg)
+ {
+ irq_hw_number_t hwirq;
+ struct irq_data *irqd;
+- u32 *lpi = arg;
+ int ret;
+
+ if (WARN_ON_ONCE(nr_irqs != 1))
+ return -EINVAL;
+
+- hwirq = *lpi;
++ ret = alloc_lpi();
++ if (ret < 0)
++ return ret;
++ hwirq = ret;
+
+ irqd = irq_domain_get_irq_data(domain, virq);
+
+@@ -771,8 +779,10 @@ static int gicv5_irq_lpi_domain_alloc(st
+ irqd_set_single_target(irqd);
+
+ ret = gicv5_irs_iste_alloc(hwirq);
+- if (ret < 0)
++ if (ret < 0) {
++ release_lpi(hwirq);
+ return ret;
++ }
+
+ gicv5_hwirq_init(hwirq, GICV5_IRQ_PRI_MI, GICV5_HWIRQ_TYPE_LPI);
+ gicv5_lpi_config_reset(irqd);
+@@ -782,7 +792,7 @@ static int gicv5_irq_lpi_domain_alloc(st
+
+ static const struct irq_domain_ops gicv5_irq_lpi_domain_ops = {
+ .alloc = gicv5_irq_lpi_domain_alloc,
+- .free = gicv5_irq_domain_free,
++ .free = gicv5_irq_lpi_domain_free,
+ };
+
+ void __init gicv5_init_lpi_domain(void)
+@@ -804,21 +814,12 @@ static int gicv5_irq_ipi_domain_alloc(st
+ {
+ struct irq_data *irqd;
+ int ret, i;
+- u32 lpi;
+
+ for (i = 0; i < nr_irqs; i++) {
+- ret = gicv5_alloc_lpi();
+- if (ret < 0)
++ ret = irq_domain_alloc_irqs_parent(domain, virq + i, 1, NULL);
++ if (ret)
+ return ret;
+
+- lpi = ret;
+-
+- ret = irq_domain_alloc_irqs_parent(domain, virq + i, 1, &lpi);
+- if (ret) {
+- gicv5_free_lpi(lpi);
+- return ret;
+- }
+-
+ irqd = irq_domain_get_irq_data(domain, virq + i);
+
+ irq_domain_set_hwirq_and_chip(domain, virq + i, i,
+@@ -844,8 +845,6 @@ static void gicv5_irq_ipi_domain_free(st
+ if (!d)
+ return;
+
+- gicv5_free_lpi(d->parent_data->hwirq);
+-
+ irq_set_handler(virq + i, NULL);
+ irq_domain_reset_irq_data(d);
+ irq_domain_free_irqs_parent(domain, virq + i, 1);
+--- a/include/linux/irqchip/arm-gic-v5.h
++++ b/include/linux/irqchip/arm-gic-v5.h
+@@ -387,8 +387,5 @@ struct gicv5_its_itt_cfg {
+ void gicv5_init_lpis(u32 max);
+ void gicv5_deinit_lpis(void);
+
+-int gicv5_alloc_lpi(void);
+-void gicv5_free_lpi(u32 lpi);
+-
+ void __init gicv5_its_of_probe(struct device_node *parent);
+ #endif
--- /dev/null
+From eb6f6d523813ead9dc2799194a2839d42c049734 Mon Sep 17 00:00:00 2001
+From: Sascha Bischoff <Sascha.Bischoff@arm.com>
+Date: Wed, 6 May 2026 09:37:23 +0000
+Subject: irqchip/gic-v5: Support range allocation for LPIs
+
+From: Sascha Bischoff <Sascha.Bischoff@arm.com>
+
+commit eb6f6d523813ead9dc2799194a2839d42c049734 upstream.
+
+The per-IPI parent allocation loop returns immediately on failure and leaks
+any parent interrupts allocated by earlier iterations.
+
+The GICv5 LPI domain now owns LPI allocation and teardown internally,
+but its irq_domain callbacks still reject requests where nr_irqs is
+greater than one. This forces child domains to allocate and free LPIs
+one at a time even when the interrupt core requests a contiguous
+range.
+
+Handle multi-interrupt allocation and teardown in the LPI domain by
+iterating over the requested range and unwinding any partially
+allocated state on failure.
+
+Allocate the parent LPIs for the IPI domain with a single range
+request as well, which cures the leakage problem.
+
+Fixes: 0f0101325876 ("irqchip/gic-v5: Add GICv5 LPI/IPI support")
+Signed-off-by: Sascha Bischoff <sascha.bischoff@arm.com>
+Signed-off-by: Thomas Gleixner <tglx@kernel.org>
+Reviewed-by: Marc Zyngier <maz@kernel.org>
+Reviewed-by: Lorenzo Pieralisi <lpieralisi@kernel.org>
+Cc: stable@vger.kernel.org
+Link: https://patch.msgid.link/20260506093634.382062-3-sascha.bischoff@arm.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/irqchip/irq-gic-v5.c | 77 +++++++++++++++++++++++--------------------
+ 1 file changed, 42 insertions(+), 35 deletions(-)
+
+--- a/drivers/irqchip/irq-gic-v5.c
++++ b/drivers/irqchip/irq-gic-v5.c
+@@ -746,15 +746,14 @@ static void gicv5_irq_lpi_domain_free(st
+ {
+ struct irq_data *d;
+
+- if (WARN_ON_ONCE(nr_irqs != 1))
+- return;
++ for (unsigned int i = 0; i < nr_irqs; i++, virq++) {
++ d = irq_domain_get_irq_data(domain, virq);
+
+- d = irq_domain_get_irq_data(domain, virq);
++ release_lpi(d->hwirq);
+
+- release_lpi(d->hwirq);
+-
+- irq_set_handler(virq, NULL);
+- irq_domain_reset_irq_data(d);
++ irq_set_handler(virq, NULL);
++ irq_domain_reset_irq_data(d);
++ }
+ }
+
+ static int gicv5_irq_lpi_domain_alloc(struct irq_domain *domain, unsigned int virq,
+@@ -762,32 +761,39 @@ static int gicv5_irq_lpi_domain_alloc(st
+ {
+ irq_hw_number_t hwirq;
+ struct irq_data *irqd;
++ unsigned int i;
+ int ret;
+
+- if (WARN_ON_ONCE(nr_irqs != 1))
+- return -EINVAL;
+-
+- ret = alloc_lpi();
+- if (ret < 0)
+- return ret;
+- hwirq = ret;
++ for (i = 0; i < nr_irqs; i++) {
++ ret = alloc_lpi();
++ if (ret < 0)
++ goto out_free_lpis;
++ hwirq = ret;
++
++ ret = gicv5_irs_iste_alloc(hwirq);
++ if (ret < 0) {
++ /* Undo partial state first, then clean up the rest */
++ release_lpi(hwirq);
++ goto out_free_lpis;
++ }
+
+- irqd = irq_domain_get_irq_data(domain, virq);
++ irqd = irq_domain_get_irq_data(domain, virq + i);
+
+- irq_domain_set_info(domain, virq, hwirq, &gicv5_lpi_irq_chip, NULL,
+- handle_fasteoi_irq, NULL, NULL);
+- irqd_set_single_target(irqd);
++ irq_domain_set_info(domain, virq + i, hwirq, &gicv5_lpi_irq_chip,
++ NULL, handle_fasteoi_irq, NULL, NULL);
++ irqd_set_single_target(irqd);
+
+- ret = gicv5_irs_iste_alloc(hwirq);
+- if (ret < 0) {
+- release_lpi(hwirq);
+- return ret;
++ gicv5_hwirq_init(hwirq, GICV5_IRQ_PRI_MI, GICV5_HWIRQ_TYPE_LPI);
++ gicv5_lpi_config_reset(irqd);
+ }
+
+- gicv5_hwirq_init(hwirq, GICV5_IRQ_PRI_MI, GICV5_HWIRQ_TYPE_LPI);
+- gicv5_lpi_config_reset(irqd);
+-
+ return 0;
++
++out_free_lpis:
++ if (i)
++ gicv5_irq_lpi_domain_free(domain, virq, i);
++
++ return ret;
+ }
+
+ static const struct irq_domain_ops gicv5_irq_lpi_domain_ops = {
+@@ -813,21 +819,21 @@ static int gicv5_irq_ipi_domain_alloc(st
+ unsigned int nr_irqs, void *arg)
+ {
+ struct irq_data *irqd;
+- int ret, i;
++ int ret;
+
+- for (i = 0; i < nr_irqs; i++) {
+- ret = irq_domain_alloc_irqs_parent(domain, virq + i, 1, NULL);
+- if (ret)
+- return ret;
++ ret = irq_domain_alloc_irqs_parent(domain, virq, nr_irqs, arg);
++ if (ret)
++ return ret;
+
+- irqd = irq_domain_get_irq_data(domain, virq + i);
++ for (unsigned int i = 0; i < nr_irqs; i++, virq++) {
++ irqd = irq_domain_get_irq_data(domain, virq);
+
+- irq_domain_set_hwirq_and_chip(domain, virq + i, i,
+- &gicv5_ipi_irq_chip, NULL);
++ irq_domain_set_hwirq_and_chip(domain, virq, i,
++ &gicv5_ipi_irq_chip, NULL);
+
+ irqd_set_single_target(irqd);
+
+- irq_set_handler(virq + i, handle_percpu_irq);
++ irq_set_handler(virq, handle_percpu_irq);
+ }
+
+ return 0;
+@@ -847,8 +853,9 @@ static void gicv5_irq_ipi_domain_free(st
+
+ irq_set_handler(virq + i, NULL);
+ irq_domain_reset_irq_data(d);
+- irq_domain_free_irqs_parent(domain, virq + i, 1);
+ }
++
++ irq_domain_free_irqs_parent(domain, virq, nr_irqs);
+ }
+
+ static const struct irq_domain_ops gicv5_irq_ipi_domain_ops = {
--- /dev/null
+From 5363b67ac8ebcc3e227dbf59fc8061949109841d Mon Sep 17 00:00:00 2001
+From: Xianwei Zhao <xianwei.zhao@amlogic.com>
+Date: Fri, 8 May 2026 07:36:54 +0000
+Subject: irqchip/meson-gpio: Use the correct register in meson_s4_gpio_irq_set_type()
+
+From: Xianwei Zhao <xianwei.zhao@amlogic.com>
+
+commit 5363b67ac8ebcc3e227dbf59fc8061949109841d upstream.
+
+meson_s4_gpio_irq_set_type() uses the both-edge trigger register for
+configuring level type and single edge mode interrupts, which is not
+correct.
+
+Use REG_EDGE_POL instead.
+
+Fixes: bbd6fcc76b39 ("irqchip: Add support for Amlogic A4 and A5 SoCs")
+Signed-off-by: Xianwei Zhao <xianwei.zhao@amlogic.com>
+Signed-off-by: Thomas Gleixner <tglx@kernel.org>
+Cc: stable@vger.kernel.org
+Link: https://patch.msgid.link/20260508-a9-gpio-irqchip-v1-1-9dc5f3e022e0@amlogic.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/irqchip/irq-meson-gpio.c | 3 +--
+ 1 file changed, 1 insertion(+), 2 deletions(-)
+
+--- a/drivers/irqchip/irq-meson-gpio.c
++++ b/drivers/irqchip/irq-meson-gpio.c
+@@ -404,8 +404,7 @@ static int meson_s4_gpio_irq_set_type(st
+ if (type & (IRQ_TYPE_EDGE_RISING | IRQ_TYPE_EDGE_FALLING))
+ val |= BIT(ctl->params->edge_single_offset + idx);
+
+- meson_gpio_irq_update_bits(ctl, params->edge_pol_reg,
+- BIT(idx) | BIT(12 + idx), val);
++ meson_gpio_irq_update_bits(ctl, REG_EDGE_POL, BIT(idx) | BIT(12 + idx), val);
+ return 0;
+ };
+
--- /dev/null
+From cefafbd561402b0fe6447449364a30315b9b1570 Mon Sep 17 00:00:00 2001
+From: Yong-Xuan Wang <yongxuan.wang@sifive.com>
+Date: Fri, 8 May 2026 02:31:21 -0700
+Subject: irqchip/riscv-imsic: Clear interrupt move state during CPU offlining
+
+From: Yong-Xuan Wang <yongxuan.wang@sifive.com>
+
+commit cefafbd561402b0fe6447449364a30315b9b1570 upstream.
+
+Affinity changes of IMSIC interrupts have to be careful to not lose an
+interrupt in the process. Each vector keeps track of an affinity change in
+progress with two pointers in struct imsic_vector.
+
+imsic_vector::move_prev points to the previous CPU target data and
+imsic_vector::move_next to the designated new CPU target data.
+
+imsic_vector::move_prev on the new CPU can only be cleared after the
+previous CPU has cleared imsic_vector::move_next, which ususally happens in
+__imsic_remote_sync().
+
+In case of CPU hot-unplug __imsic_remote_sync() is not invoked because the
+CPU is already marked offline. That means imsic_vector::move_prev becomes
+stale until the CPU is onlined again.
+
+The stale pointer prevents further affinity changes for the affected
+interrupts.
+
+Solve this by clearing the imsic_vector::move_prev pointers in the CPU
+hotplug offline path.
+
+[ tglx: Replace word salad in change log ]
+
+Fixes: 0f67911e821c ("irqchip/riscv-imsic: Separate next and previous pointers in IMSIC vector")
+Signed-off-by: Yong-Xuan Wang <yongxuan.wang@sifive.com>
+Signed-off-by: Thomas Gleixner <tglx@kernel.org>
+Cc: stable@vger.kernel.org
+Link: https://patch.msgid.link/20260508-imsic-v2-1-e9f08dd46cf5@sifive.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/irqchip/irq-riscv-imsic-early.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/drivers/irqchip/irq-riscv-imsic-early.c
++++ b/drivers/irqchip/irq-riscv-imsic-early.c
+@@ -163,6 +163,8 @@ static int imsic_dying_cpu(unsigned int
+ /* Cleanup IPIs */
+ imsic_ipi_dying_cpu();
+
++ imsic_local_sync_all(false);
++
+ /* Mark per-CPU IMSIC state as offline */
+ imsic_state_offline();
+
--- /dev/null
+From 28b0a2ab8c82d0bbdeb8013029c67c978ce6e4bf Mon Sep 17 00:00:00 2001
+From: Raphael Zimmer <raphael.zimmer@tu-ilmenau.de>
+Date: Tue, 12 May 2026 18:16:40 +0200
+Subject: libceph: Fix potential null-ptr-deref in decode_choose_args()
+
+From: Raphael Zimmer <raphael.zimmer@tu-ilmenau.de>
+
+commit 28b0a2ab8c82d0bbdeb8013029c67c978ce6e4bf upstream.
+
+A message of type CEPH_MSG_OSD_MAP contains an OSD map that itself
+contains a CRUSH map. When decoding this CRUSH map in crush_decode(), an
+array of max_buckets CRUSH buckets is decoded, where some indices may
+not refer to actual buckets and are therefore set to NULL. The received
+CRUSH map may optionally contain choose_args that get decoded in
+decode_choose_args(). When decoding a crush_choose_arg_map, a series of
+choose_args for different buckets is decoded, with the bucket_index
+being read from the incoming message. It is only checked that the bucket
+index does not exceed max_buckets, but not that it doesn't point to an
+index with a NULL bucket. If a (potentially corrupted) message contains
+a crush_choose_arg_map including such a bucket_index, a null pointer
+dereference may occur in the subsequent processing when attempting to
+access the bucket with the given index.
+
+This patch fixes the issue by extending the affected check. Now, it is
+only attempted to access the bucket if it is not NULL.
+
+Cc: stable@vger.kernel.org
+Signed-off-by: Raphael Zimmer <raphael.zimmer@tu-ilmenau.de>
+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/osdmap.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/net/ceph/osdmap.c
++++ b/net/ceph/osdmap.c
+@@ -390,7 +390,8 @@ static int decode_choose_args(void **p,
+ goto fail;
+
+ if (arg->ids_size &&
+- arg->ids_size != c->buckets[bucket_index]->size)
++ (!c->buckets[bucket_index] ||
++ arg->ids_size != c->buckets[bucket_index]->size))
+ goto e_inval;
+ }
+
--- /dev/null
+From 4c79fc2d598694bda845b46229c9d48b65042970 Mon Sep 17 00:00:00 2001
+From: Raphael Zimmer <raphael.zimmer@tu-ilmenau.de>
+Date: Wed, 22 Apr 2026 10:47:13 +0200
+Subject: libceph: Fix potential out-of-bounds access in crush_decode()
+
+From: Raphael Zimmer <raphael.zimmer@tu-ilmenau.de>
+
+commit 4c79fc2d598694bda845b46229c9d48b65042970 upstream.
+
+A message of type CEPH_MSG_OSD_MAP containing a crush map with at least
+one bucket has two fields holding the bucket algorithm. If the values
+in these two fields differ, an out-of-bounds access can occur. This is
+the case because the first algorithm field (alg) is used to allocate
+the correct amount of memory for a bucket of this type, while the second
+algorithm field inside the bucket (b->alg) is used in the subsequent
+processing.
+
+This patch fixes the issue by adding a check that compares alg and
+b->alg and aborts the processing in case they differ. Furthermore,
+b->alg is set to 0 in this case, because the destruction of the crush
+map also uses this field to determine the bucket type, which can again
+result in an out-of-bounds access when trying to free the memory pointed
+to by the fields of the bucket. To correctly free the memory allocated
+for the bucket in such a case, the corresponding call to kfree is moved
+from the algorithm-specific crush_destroy_bucket functions to the
+generic crush_destroy_bucket().
+
+Cc: stable@vger.kernel.org
+Signed-off-by: Raphael Zimmer <raphael.zimmer@tu-ilmenau.de>
+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/crush/crush.c | 6 +-----
+ net/ceph/osdmap.c | 4 ++++
+ 2 files changed, 5 insertions(+), 5 deletions(-)
+
+--- a/net/ceph/crush/crush.c
++++ b/net/ceph/crush/crush.c
+@@ -47,7 +47,6 @@ int crush_get_bucket_item_weight(const s
+ void crush_destroy_bucket_uniform(struct crush_bucket_uniform *b)
+ {
+ kfree(b->h.items);
+- kfree(b);
+ }
+
+ void crush_destroy_bucket_list(struct crush_bucket_list *b)
+@@ -55,14 +54,12 @@ void crush_destroy_bucket_list(struct cr
+ kfree(b->item_weights);
+ kfree(b->sum_weights);
+ kfree(b->h.items);
+- kfree(b);
+ }
+
+ void crush_destroy_bucket_tree(struct crush_bucket_tree *b)
+ {
+ kfree(b->h.items);
+ kfree(b->node_weights);
+- kfree(b);
+ }
+
+ void crush_destroy_bucket_straw(struct crush_bucket_straw *b)
+@@ -70,14 +67,12 @@ void crush_destroy_bucket_straw(struct c
+ kfree(b->straws);
+ kfree(b->item_weights);
+ kfree(b->h.items);
+- kfree(b);
+ }
+
+ void crush_destroy_bucket_straw2(struct crush_bucket_straw2 *b)
+ {
+ kfree(b->item_weights);
+ kfree(b->h.items);
+- kfree(b);
+ }
+
+ void crush_destroy_bucket(struct crush_bucket *b)
+@@ -99,6 +94,7 @@ void crush_destroy_bucket(struct crush_b
+ crush_destroy_bucket_straw2((struct crush_bucket_straw2 *)b);
+ break;
+ }
++ kfree(b);
+ }
+
+ /**
+--- a/net/ceph/osdmap.c
++++ b/net/ceph/osdmap.c
+@@ -518,6 +518,10 @@ static struct crush_map *crush_decode(vo
+ b->id = ceph_decode_32(p);
+ b->type = ceph_decode_16(p);
+ b->alg = ceph_decode_8(p);
++ if (b->alg != alg) {
++ b->alg = 0;
++ goto bad;
++ }
+ b->hash = ceph_decode_8(p);
+ b->weight = ceph_decode_32(p);
+ b->size = ceph_decode_32(p);
--- /dev/null
+From 35d0ed82d03e5ee77ea4f31f20e29562a7721649 Mon Sep 17 00:00:00 2001
+From: Raphael Zimmer <raphael.zimmer@tu-ilmenau.de>
+Date: Tue, 5 May 2026 11:08:12 +0200
+Subject: libceph: Fix potential out-of-bounds access in osdmap_decode()
+
+From: Raphael Zimmer <raphael.zimmer@tu-ilmenau.de>
+
+commit 35d0ed82d03e5ee77ea4f31f20e29562a7721649 upstream.
+
+When decoding osd_state and osd_weight from an incoming osdmap in
+osdmap_decode(), both are decoded for each osd, i.e., map->max_osd
+times. The ceph_decode_need() check only accounts for
+sizeof(*map->osd_weight) once. This can potentially result in an
+out-of-bounds memory access if the incoming message is corrupted such
+that the max_osd value exceeds the actual content of the osdmap message.
+
+This patch fixes the issue by changing the corresponding part in the
+ceph_decode_need() check to account for
+map->max_osd*sizeof(*map->osd_weight).
+
+Cc: stable@vger.kernel.org
+Fixes: dcbc919a5dc8 ("libceph: switch osdmap decoding to use ceph_decode_entity_addr")
+Signed-off-by: Raphael Zimmer <raphael.zimmer@tu-ilmenau.de>
+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/osdmap.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/net/ceph/osdmap.c
++++ b/net/ceph/osdmap.c
+@@ -1703,7 +1703,7 @@ static int osdmap_decode(void **p, void
+ ceph_decode_need(p, end, 3*sizeof(u32) +
+ map->max_osd*(struct_v >= 5 ? sizeof(u32) :
+ sizeof(u8)) +
+- sizeof(*map->osd_weight), e_inval);
++ map->max_osd*sizeof(*map->osd_weight), e_inval);
+ if (ceph_decode_32(p) != map->max_osd)
+ goto e_inval;
+
--- /dev/null
+From d289478cfc0bcf81c7914200d6abdcb78bd04ded Mon Sep 17 00:00:00 2001
+From: Raphael Zimmer <raphael.zimmer@tu-ilmenau.de>
+Date: Tue, 12 May 2026 09:29:30 +0200
+Subject: libceph: handle rbtree insertion error in decode_choose_args()
+
+From: Raphael Zimmer <raphael.zimmer@tu-ilmenau.de>
+
+commit d289478cfc0bcf81c7914200d6abdcb78bd04ded upstream.
+
+A message of type CEPH_MSG_OSD_MAP contains an OSD map that itself
+contains a CRUSH map. The received CRUSH map may optionally contain
+choose_args that get decoded in decode_choose_args(). In this function,
+num_choose_arg_maps is read from the message, and a corresponding number
+of crush_choose_arg_maps gets decoded afterwards. Each
+crush_choose_arg_map has a choose_args_index, which serves as the key
+when inserting it into the choose_args rbtree of the decoded crush_map.
+If a (potentially corrupted) message contains two crush_choose_arg_maps
+with the same index, the assertion in insert_choose_arg_map() triggers a
+kernel BUG when trying to insert the second crush_choose_arg_map.
+
+This patch fixes the issue by switching to the non-asserting rbtree
+insertion function and rejecting the message if the insertion fails.
+
+[ idryomov: changelog ]
+
+Cc: stable@vger.kernel.org
+Signed-off-by: Raphael Zimmer <raphael.zimmer@tu-ilmenau.de>
+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/osdmap.c | 5 ++++-
+ 1 file changed, 4 insertions(+), 1 deletion(-)
+
+--- a/net/ceph/osdmap.c
++++ b/net/ceph/osdmap.c
+@@ -395,7 +395,10 @@ static int decode_choose_args(void **p,
+ goto e_inval;
+ }
+
+- insert_choose_arg_map(&c->choose_args, arg_map);
++ if (!__insert_choose_arg_map(&c->choose_args, arg_map)) {
++ ret = -EEXIST;
++ goto fail;
++ }
+ }
+
+ return 0;
--- /dev/null
+From 0aad5704c6b4d14007d4eab15883e8524e4310f4 Mon Sep 17 00:00:00 2001
+From: Paulo Alcantara <pc@manguebit.org>
+Date: Tue, 12 May 2026 13:33:46 +0100
+Subject: netfs: fix error handling in netfs_extract_user_iter()
+
+From: Paulo Alcantara <pc@manguebit.org>
+
+commit 0aad5704c6b4d14007d4eab15883e8524e4310f4 upstream.
+
+In netfs_extract_user_iter(), if iov_iter_extract_pages() failed to
+extract user pages, bail out on -ENOMEM, otherwise return the error
+code only if @npages == 0, allowing short DIO reads and writes to be
+issued.
+
+This fixes mmapstress02 from LTP tests against CIFS.
+
+Fixes: 85dd2c8ff368 ("netfs: Add a function to extract a UBUF or IOVEC into a BVEC iterator")
+Reported-by: Xiaoli Feng <xifeng@redhat.com>
+Signed-off-by: Paulo Alcantara (Red Hat) <pc@manguebit.org>
+Signed-off-by: David Howells <dhowells@redhat.com>
+Link: https://patch.msgid.link/20260512123404.719402-10-dhowells@redhat.com
+Cc: netfs@lists.linux.dev
+Cc: stable@vger.kernel.org
+Cc: linux-cifs@vger.kernel.org
+Cc: linux-fsdevel@vger.kernel.org
+Signed-off-by: Christian Brauner <brauner@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/netfs/iterator.c | 13 ++++++++++---
+ 1 file changed, 10 insertions(+), 3 deletions(-)
+
+--- a/fs/netfs/iterator.c
++++ b/fs/netfs/iterator.c
+@@ -22,7 +22,7 @@
+ *
+ * Extract the page fragments from the given amount of the source iterator and
+ * build up a second iterator that refers to all of those bits. This allows
+- * the original iterator to disposed of.
++ * the original iterator to be disposed of.
+ *
+ * @extraction_flags can have ITER_ALLOW_P2PDMA set to request peer-to-peer DMA be
+ * allowed on the pages extracted.
+@@ -67,8 +67,8 @@ ssize_t netfs_extract_user_iter(struct i
+ ret = iov_iter_extract_pages(orig, &pages, count,
+ max_pages - npages, extraction_flags,
+ &offset);
+- if (ret < 0) {
+- pr_err("Couldn't get user pages (rc=%zd)\n", ret);
++ if (unlikely(ret <= 0)) {
++ ret = ret ?: -EIO;
+ break;
+ }
+
+@@ -97,6 +97,13 @@ ssize_t netfs_extract_user_iter(struct i
+ npages += cur_npages;
+ }
+
++ if (ret < 0 && (ret == -ENOMEM || npages == 0)) {
++ for (i = 0; i < npages; i++)
++ unpin_user_page(bv[i].bv_page);
++ kvfree(bv);
++ return ret;
++ }
++
+ iov_iter_bvec(new, orig->data_source, bv, npages, orig_len - count);
+ return npages;
+ }
--- /dev/null
+From 304d81a2fbf2b454def4debcb38ea173911b72cd Mon Sep 17 00:00:00 2001
+From: Scott Mayhew <smayhew@redhat.com>
+Date: Tue, 7 Apr 2026 18:08:57 -0400
+Subject: nfsd: fix file change detection in CB_GETATTR
+
+From: Scott Mayhew <smayhew@redhat.com>
+
+commit 304d81a2fbf2b454def4debcb38ea173911b72cd upstream.
+
+RFC 8881, section 10.4.3 doesn't say anything about caching the file
+size in the delegation record, nor does it say anything about comparing
+a cached file size with the size reported by the client in the
+CB_GETATTR reply for the purpose of determining if the client holds
+modified data for the file.
+
+What section 10.4.3 of RFC 8881 does say is that the server should
+compare the *current* file size with the size reported by the client
+holding the delegation in the CB_GETATTR reply, and if they differ to
+treat it as a modification regardless of the change attribute retrieved
+via the CB_GETATTR.
+
+Doing otherwise would cause the server to believe the client holding the
+delegation has a modified version of the file, even if the client
+flushed the modifications to the server prior to the CB_GETATTR. This
+would have the added side effect of subsequent CB_GETATTRs causing
+updates to the mtime, ctime, and change attribute even if the client
+holding the delegation makes no further updates to the file.
+
+Modify nfsd4_deleg_getattr_conflict() to obtain the current file size
+via i_size_read(). Retain the ncf_cur_fsize field, since it's a
+convenient way to return the file size back to nfsd4_encode_fattr4(),
+but don't use it for the purpose of detecting file changes. Remove the
+unnecessary initialization of ncf_cur_fsize in nfs4_open_delegation().
+
+Also, if we recall the delegation (because the client didn't respond to
+the CB_GETATTR), then skip the logic that checks the nfs4_cb_fattr
+fields.
+
+Fixes: c5967721e106 ("NFSD: handle GETATTR conflict with write delegation")
+Cc: stable@vger.kernel.org
+Signed-off-by: Scott Mayhew <smayhew@redhat.com>
+Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/nfsd/nfs4state.c | 13 ++++++++-----
+ 1 file changed, 8 insertions(+), 5 deletions(-)
+
+--- a/fs/nfsd/nfs4state.c
++++ b/fs/nfsd/nfs4state.c
+@@ -6350,7 +6350,6 @@ nfs4_open_delegation(struct svc_rqst *rq
+ }
+ open->op_delegate_type = deleg_ts ? OPEN_DELEGATE_WRITE_ATTRS_DELEG :
+ OPEN_DELEGATE_WRITE;
+- dp->dl_cb_fattr.ncf_cur_fsize = stat.size;
+ dp->dl_cb_fattr.ncf_initial_cinfo = nfsd4_change_attribute(&stat);
+ dp->dl_atime = stat.atime;
+ dp->dl_ctime = stat.ctime;
+@@ -9396,11 +9395,15 @@ nfsd4_deleg_getattr_conflict(struct svc_
+ if (status != nfserr_jukebox ||
+ !nfsd_wait_for_delegreturn(rqstp, inode))
+ goto out_status;
++ status = nfs_ok;
++ goto out_status;
++ }
++ if (!ncf->ncf_file_modified) {
++ if (ncf->ncf_initial_cinfo != ncf->ncf_cb_change)
++ ncf->ncf_file_modified = true;
++ else if (i_size_read(inode) != ncf->ncf_cb_fsize)
++ ncf->ncf_file_modified = true;
+ }
+- if (!ncf->ncf_file_modified &&
+- (ncf->ncf_initial_cinfo != ncf->ncf_cb_change ||
+- ncf->ncf_cur_fsize != ncf->ncf_cb_fsize))
+- ncf->ncf_file_modified = true;
+ if (ncf->ncf_file_modified) {
+ int err;
+
--- /dev/null
+From a6ab75639e23169a741b0b2e12191fd8acb32c73 Mon Sep 17 00:00:00 2001
+From: Nick Chan <towinchenmi@gmail.com>
+Date: Thu, 14 May 2026 21:16:01 +0800
+Subject: nvme-apple: Reset q->sq_tail during queue init
+
+From: Nick Chan <towinchenmi@gmail.com>
+
+commit a6ab75639e23169a741b0b2e12191fd8acb32c73 upstream.
+
+Fixes a "duplicate tag error for tag 0" firmware crash during controller
+reset while setting up a queue on Apple A11 / T8015 caused by stale
+entries in the submission queue due to an invalid sq_tail offset after
+reset.
+
+Fixes: 04d8ecf37b5e ("nvme: apple: Add Apple A11 support")
+Cc: stable@vger.kernel.org
+Suggested-by: Yuriy Havrylyuk <yhavry@gmail.com>
+Reviewed-by: Sven Peter <sven@kernel.org>
+Signed-off-by: Nick Chan <towinchenmi@gmail.com>
+Signed-off-by: Keith Busch <kbusch@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/nvme/host/apple.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/nvme/host/apple.c
++++ b/drivers/nvme/host/apple.c
+@@ -1009,6 +1009,7 @@ static void apple_nvme_init_queue(struct
+ unsigned int depth = apple_nvme_queue_depth(q);
+ struct apple_nvme *anv = queue_to_apple_nvme(q);
+
++ q->sq_tail = 0;
+ q->cq_head = 0;
+ q->cq_phase = 1;
+ if (anv->hw->has_lsq_nvmmu)
--- /dev/null
+From ad3bff944c0f4f2e913298a9664391af32f87491 Mon Sep 17 00:00:00 2001
+From: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
+Date: Thu, 30 Apr 2026 08:11:01 -0700
+Subject: platform/x86: intel: Move debugfs register before creating devices
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
+
+commit ad3bff944c0f4f2e913298a9664391af32f87491 upstream.
+
+It is possible that the driver handling device is enumerated before
+registering debugfs. If the driver wants to access debugfs by calling
+tpmi_get_debugfs_dir(), this will return error in this case.
+
+Hence register debugfs before creating devices.
+
+Fixes: 811f67c51636 ("platform/x86/intel/tpmi: Add new auxiliary driver for performance limits")
+Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
+Cc: Stable@vger.kernel.org
+Link: https://patch.msgid.link/20260430151103.1549733-2-srinivas.pandruvada@linux.intel.com
+Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
+Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/platform/x86/intel/vsec_tpmi.c | 10 ++++++----
+ 1 file changed, 6 insertions(+), 4 deletions(-)
+
+--- a/drivers/platform/x86/intel/vsec_tpmi.c
++++ b/drivers/platform/x86/intel/vsec_tpmi.c
+@@ -813,10 +813,6 @@ static int intel_vsec_tpmi_init(struct a
+
+ auxiliary_set_drvdata(auxdev, tpmi_info);
+
+- ret = tpmi_create_devices(tpmi_info);
+- if (ret)
+- return ret;
+-
+ /*
+ * Allow debugfs when security policy allows. Everything this debugfs
+ * interface provides, can also be done via /dev/mem access. If
+@@ -826,6 +822,12 @@ static int intel_vsec_tpmi_init(struct a
+ if (!security_locked_down(LOCKDOWN_DEV_MEM) && capable(CAP_SYS_RAWIO))
+ tpmi_dbgfs_register(tpmi_info);
+
++ ret = tpmi_create_devices(tpmi_info);
++ if (ret) {
++ debugfs_remove_recursive(tpmi_info->dbgfs_dir);
++ return ret;
++ }
++
+ return 0;
+ }
+
--- /dev/null
+From 7e27896e16a1c450085c3fe020eeb1b223880f37 Mon Sep 17 00:00:00 2001
+From: "Derek J. Clark" <derekjohn.clark@gmail.com>
+Date: Sun, 10 May 2026 04:25:37 +0000
+Subject: platform/x86: lenovo-wmi-helpers: Move gamezone enums to wmi-helpers
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Derek J. Clark <derekjohn.clark@gmail.com>
+
+commit 7e27896e16a1c450085c3fe020eeb1b223880f37 upstream.
+
+In a later patch in the series the thermal mode enum will be accessed
+across three separate drivers (wmi-capdata, wmi-gamezonem and wmi-other).
+An additional patch in the series will also add a function prototype that
+needs to reference this enum in wmi-helpers.h. To avoid having all these
+drivers begin to import each others headers, and to avoid declaring an
+opaque enum to hande the second case, move the thermal mode enum to
+helpers where it can be safely accessed by everything that needs it from
+a single import.
+
+While at it, since the gamezone_events_type enum is the only remaining
+item in the header, move that as well and remove the gamezone header
+entirely.
+
+Cc: stable@vger.kernel.org
+Reviewed-by: Mark Pearson <mpearson-lenovo@squebb.ca>
+Reviewed-by: Rong Zhang <i@rong.moe>
+Tested-by: Rong Zhang <i@rong.moe>
+Signed-off-by: Derek J. Clark <derekjohn.clark@gmail.com>
+Link: https://patch.msgid.link/20260510042546.436874-8-derekjohn.clark@gmail.com
+Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
+Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/platform/x86/lenovo/wmi-events.c | 2 +-
+ drivers/platform/x86/lenovo/wmi-gamezone.c | 1 -
+ drivers/platform/x86/lenovo/wmi-gamezone.h | 20 --------------------
+ drivers/platform/x86/lenovo/wmi-helpers.h | 13 +++++++++++++
+ drivers/platform/x86/lenovo/wmi-other.c | 1 -
+ 5 files changed, 14 insertions(+), 23 deletions(-)
+ delete mode 100644 drivers/platform/x86/lenovo/wmi-gamezone.h
+
+--- a/drivers/platform/x86/lenovo/wmi-events.c
++++ b/drivers/platform/x86/lenovo/wmi-events.c
+@@ -17,7 +17,7 @@
+ #include <linux/wmi.h>
+
+ #include "wmi-events.h"
+-#include "wmi-gamezone.h"
++#include "wmi-helpers.h"
+
+ #define THERMAL_MODE_EVENT_GUID "D320289E-8FEA-41E0-86F9-911D83151B5F"
+
+--- a/drivers/platform/x86/lenovo/wmi-gamezone.c
++++ b/drivers/platform/x86/lenovo/wmi-gamezone.c
+@@ -21,7 +21,6 @@
+ #include <linux/wmi.h>
+
+ #include "wmi-events.h"
+-#include "wmi-gamezone.h"
+ #include "wmi-helpers.h"
+ #include "wmi-other.h"
+
+--- a/drivers/platform/x86/lenovo/wmi-gamezone.h
++++ /dev/null
+@@ -1,20 +0,0 @@
+-/* SPDX-License-Identifier: GPL-2.0-or-later */
+-
+-/* Copyright (C) 2025 Derek J. Clark <derekjohn.clark@gmail.com> */
+-
+-#ifndef _LENOVO_WMI_GAMEZONE_H_
+-#define _LENOVO_WMI_GAMEZONE_H_
+-
+-enum gamezone_events_type {
+- LWMI_GZ_GET_THERMAL_MODE = 1,
+-};
+-
+-enum thermal_mode {
+- LWMI_GZ_THERMAL_MODE_QUIET = 0x01,
+- LWMI_GZ_THERMAL_MODE_BALANCED = 0x02,
+- LWMI_GZ_THERMAL_MODE_PERFORMANCE = 0x03,
+- LWMI_GZ_THERMAL_MODE_EXTREME = 0xE0, /* Ver 6+ */
+- LWMI_GZ_THERMAL_MODE_CUSTOM = 0xFF,
+-};
+-
+-#endif /* !_LENOVO_WMI_GAMEZONE_H_ */
+--- a/drivers/platform/x86/lenovo/wmi-helpers.h
++++ b/drivers/platform/x86/lenovo/wmi-helpers.h
+@@ -14,6 +14,19 @@ struct wmi_method_args_32 {
+ u32 arg1;
+ };
+
++enum lwmi_event_type {
++ LWMI_GZ_GET_THERMAL_MODE = 0x01,
++};
++
++enum thermal_mode {
++ LWMI_GZ_THERMAL_MODE_NONE = 0x00,
++ LWMI_GZ_THERMAL_MODE_QUIET = 0x01,
++ LWMI_GZ_THERMAL_MODE_BALANCED = 0x02,
++ LWMI_GZ_THERMAL_MODE_PERFORMANCE = 0x03,
++ LWMI_GZ_THERMAL_MODE_EXTREME = 0xE0, /* Ver 6+ */
++ LWMI_GZ_THERMAL_MODE_CUSTOM = 0xFF,
++};
++
+ int lwmi_dev_evaluate_int(struct wmi_device *wdev, u8 instance, u32 method_id,
+ unsigned char *buf, size_t size, u32 *retval);
+
+--- a/drivers/platform/x86/lenovo/wmi-other.c
++++ b/drivers/platform/x86/lenovo/wmi-other.c
+@@ -36,7 +36,6 @@
+
+ #include "wmi-capdata01.h"
+ #include "wmi-events.h"
+-#include "wmi-gamezone.h"
+ #include "wmi-helpers.h"
+ #include "wmi-other.h"
+ #include "../firmware_attributes_class.h"
--- /dev/null
+From 71f3843e0f81e3c097a088c1121154bb9a44da0a Mon Sep 17 00:00:00 2001
+From: "Derek J. Clark" <derekjohn.clark@gmail.com>
+Date: Sun, 10 May 2026 04:25:35 +0000
+Subject: platform/x86: lenovo-wmi-other: Fix tunable_attr_01 struct members
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Derek J. Clark <derekjohn.clark@gmail.com>
+
+commit 71f3843e0f81e3c097a088c1121154bb9a44da0a upstream.
+
+In struct tunable_attr_01 the capdata pointer is unused and the size of
+the id members is u32 when it should be u8. Fix these prior to adding
+additional members.
+
+No functional change intended.
+
+Reviewed-by: Mark Pearson <mpearson-lenovo@squebb.ca>
+Cc: stable@vger.kernel.org
+Reviewed-by: Rong Zhang <i@rong.moe>
+Tested-by: Rong Zhang <i@rong.moe>
+Signed-off-by: Derek J. Clark <derekjohn.clark@gmail.com>
+Link: https://patch.msgid.link/20260510042546.436874-6-derekjohn.clark@gmail.com
+Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
+Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/platform/x86/lenovo/wmi-other.c | 7 +++----
+ 1 file changed, 3 insertions(+), 4 deletions(-)
+
+--- a/drivers/platform/x86/lenovo/wmi-other.c
++++ b/drivers/platform/x86/lenovo/wmi-other.c
+@@ -82,11 +82,10 @@ struct lwmi_om_priv {
+ };
+
+ struct tunable_attr_01 {
+- struct capdata01 *capdata;
+ struct device *dev;
+- u32 feature_id;
+- u32 device_id;
+- u32 type_id;
++ u8 feature_id;
++ u8 device_id;
++ u8 type_id;
+ };
+
+ static struct tunable_attr_01 ppt_pl1_spl = {
--- /dev/null
+From 108d7f951271cbd36ca36efc5e5d106966f5180c Mon Sep 17 00:00:00 2001
+From: Ma Ke <make24@iscas.ac.cn>
+Date: Sun, 16 Nov 2025 10:44:11 +0800
+Subject: powerpc/warp: Fix error handling in pika_dtm_thread
+
+From: Ma Ke <make24@iscas.ac.cn>
+
+commit 108d7f951271cbd36ca36efc5e5d106966f5180c upstream.
+
+pika_dtm_thread() acquires client through of_find_i2c_device_by_node()
+but fails to release it in error handling path. This could result in a
+reference count leak, preventing proper cleanup and potentially
+leading to resource exhaustion. Add put_device() to release the
+reference in the error handling path.
+
+Found by code review.
+
+Cc: stable@vger.kernel.org
+Fixes: 3984114f0562 ("powerpc/warp: Platform fix for i2c change")
+Signed-off-by: Ma Ke <make24@iscas.ac.cn>
+Reviewed-by: Christophe Leroy <christophe.leroy@csgroup.eu>
+Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com>
+Link: https://patch.msgid.link/20251116024411.21968-1-make24@iscas.ac.cn
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/powerpc/platforms/44x/warp.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/arch/powerpc/platforms/44x/warp.c
++++ b/arch/powerpc/platforms/44x/warp.c
+@@ -293,6 +293,8 @@ static int pika_dtm_thread(void __iomem
+ schedule_timeout(HZ);
+ }
+
++ put_device(&client->dev);
++
+ return 0;
+ }
+
--- /dev/null
+From b69bcb13ed7024a84d6cd8ad330f1e32782fcf28 Mon Sep 17 00:00:00 2001
+From: Vivian Wang <wangruikang@iscas.ac.cn>
+Date: Wed, 1 Apr 2026 09:53:17 +0800
+Subject: riscv: misaligned: Make enabling delegation depend on NONPORTABLE
+
+From: Vivian Wang <wangruikang@iscas.ac.cn>
+
+commit b69bcb13ed7024a84d6cd8ad330f1e32782fcf28 upstream.
+
+The unaligned access emulation code in Linux has various deficiencies.
+For example, it doesn't emulate vector instructions [1] [2], and doesn't
+emulate KVM guest accesses. Therefore, requesting misaligned exception
+delegation with SBI FWFT actually regresses vector instructions' and KVM
+guests' behavior.
+
+Until Linux can handle it properly, guard these sbi_fwft_set() calls
+behind RISCV_SBI_FWFT_DELEGATE_MISALIGNED, which in turn depends on
+NONPORTABLE. Those who are sure that this wouldn't be a problem can
+enable this option, perhaps getting better performance.
+
+The rest of the existing code proceeds as before, except as if
+SBI_FWFT_MISALIGNED_EXC_DELEG is not available, to handle any remaining
+address misaligned exceptions on a best-effort basis. The KVM SBI FWFT
+implementation is also not touched, but it is disabled if the firmware
+emulates unaligned accesses.
+
+Cc: stable@vger.kernel.org
+Fixes: cf5a8abc6560 ("riscv: misaligned: request misaligned exception from SBI")
+Reported-by: Songsong Zhang <U2FsdGVkX1@gmail.com> # KVM
+Link: https://lore.kernel.org/linux-riscv/38ce44c1-08cf-4e3f-8ade-20da224f529c@iscas.ac.cn/ [1]
+Link: https://lore.kernel.org/linux-riscv/b3cfcdac-0337-4db0-a611-258f2868855f@iscas.ac.cn/ [2]
+Signed-off-by: Vivian Wang <wangruikang@iscas.ac.cn>
+Acked-by: Conor Dooley <conor.dooley@microchip.com>
+Link: https://patch.msgid.link/20260401-riscv-misaligned-dont-delegate-v2-1-5014a288c097@iscas.ac.cn
+Signed-off-by: Paul Walmsley <pjw@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/riscv/Kconfig | 22 ++++++++++++++++++++++
+ arch/riscv/kernel/traps_misaligned.c | 2 +-
+ 2 files changed, 23 insertions(+), 1 deletion(-)
+
+--- a/arch/riscv/Kconfig
++++ b/arch/riscv/Kconfig
+@@ -925,6 +925,28 @@ config RISCV_VECTOR_MISALIGNED
+ help
+ Enable detecting support for vector misaligned loads and stores.
+
++config RISCV_SBI_FWFT_DELEGATE_MISALIGNED
++ bool "Request firmware delegation of unaligned access exceptions"
++ depends on RISCV_SBI
++ depends on NONPORTABLE
++ help
++ Use SBI FWFT to request delegation of load address misaligned and
++ store address misaligned exceptions, if possible, and prefer Linux
++ kernel emulation of these accesses to firmware emulation.
++
++ Unfortunately, Linux's emulation is still incomplete. Namely, it
++ currently does not handle vector instructions and KVM guest accesses.
++ On platforms where these accesses would have been handled by firmware,
++ enabling this causes unexpected kernel oopses, userspaces crashes and
++ KVM guest crashes. If you are sure that these are not a problem for
++ your platform, you can say Y here, which may improve performance.
++
++ Saying N here will not worsen emulation support for unaligned accesses
++ even in the case where the firmware also has incomplete support. It
++ simply keeps the firmware's emulation enabled.
++
++ If you don't know what to do here, say N.
++
+ choice
+ prompt "Unaligned Accesses Support"
+ default RISCV_PROBE_UNALIGNED_ACCESS
+--- a/arch/riscv/kernel/traps_misaligned.c
++++ b/arch/riscv/kernel/traps_misaligned.c
+@@ -584,7 +584,7 @@ static int cpu_online_check_unaligned_ac
+
+ static bool misaligned_traps_delegated;
+
+-#ifdef CONFIG_RISCV_SBI
++#if defined(CONFIG_RISCV_SBI_FWFT_DELEGATE_MISALIGNED)
+
+ static int cpu_online_sbi_unaligned_setup(unsigned int cpu)
+ {
ata-libata-scsi-fix-requeue-of-deferred-ata-pass-thr.patch
media-staging-imx-configure-src_mux-in-csi_start.patch
bluetooth-btmtk-accept-too-short-wmt-func_ctrl-events.patch
+nvme-apple-reset-q-sq_tail-during-queue-init.patch
+smb-client-fix-possible-infinite-loop-and-oob-read-in-symlink_data.patch
+drm-loongson-use-managed-kms-polling.patch
+drm-replace-old-pointer-to-new-idr.patch
+drm-i915-dp-fix-vsc-dynamic-range-signaling-for-rgb-formats.patch
+platform-x86-intel-move-debugfs-register-before-creating-devices.patch
+platform-x86-lenovo-wmi-helpers-move-gamezone-enums-to-wmi-helpers.patch
+platform-x86-lenovo-wmi-other-fix-tunable_attr_01-struct-members.patch
+accel-rocket-fix-prep_bo-ioctl-leaking-positive-return-from-dma_resv_wait_timeout.patch
+alsa-hda-realtek-add-mute-led-quirk-for-hp-pavilion-laptop-16-ag0xxx.patch
+alsa-hda-realtek-add-quirk-for-samsung-galaxy-book5-360-headphone.patch
+alsa-usb-audio-bound-midi-2.0-endpoint-descriptor-scans.patch
+alsa-usb-audio-bound-midi-endpoint-descriptor-scans.patch
+alsa-usb-audio-qcom-check-offload-mapping-failures.patch
+btrfs-only-release-the-dirty-pages-io-tree-after-successful-writes.patch
+ceph-fix-a-buffer-leak-in-__ceph_setxattr.patch
+ceph-fix-bug_on-in-__ceph_build_xattrs_blob-due-to-stale-blob-size.patch
+io-wq-check-that-the-predecessor-is-hashed-in-io_wq_remove_pending.patch
+iommu-amd-bounds-check-devid-in-__rlookup_amd_iommu.patch
+x86-kexec-push-kjump-return-address-even-for-non-kjump-kexec.patch
+xfs-fix-memory-leak-on-error-in-xfs_alloc_zone_info.patch
+virt-sev-guest-do-not-use-host-controlled-page-order-in-cleanup-path.patch
+riscv-misaligned-make-enabling-delegation-depend-on-nonportable.patch
+powerpc-warp-fix-error-handling-in-pika_dtm_thread.patch
+netfs-fix-error-handling-in-netfs_extract_user_iter.patch
+nfsd-fix-file-change-detection-in-cb_getattr.patch
+irqchip-riscv-imsic-clear-interrupt-move-state-during-cpu-offlining.patch
+irqchip-meson-gpio-use-the-correct-register-in-meson_s4_gpio_irq_set_type.patch
+irqchip-gic-v5-move-lpi-allocation-into-the-lpi-domain.patch
+irqchip-gic-v5-support-range-allocation-for-lpis.patch
+irqchip-gic-v5-allocate-its-parent-lpis-as-a-range.patch
+libceph-fix-potential-out-of-bounds-access-in-osdmap_decode.patch
+libceph-fix-potential-null-ptr-deref-in-decode_choose_args.patch
+libceph-fix-potential-out-of-bounds-access-in-crush_decode.patch
+libceph-handle-rbtree-insertion-error-in-decode_choose_args.patch
+iommu-vt-d-disable-dmar-for-intel-q35-igfx.patch
+iommu-vt-d-fix-oops-due-to-out-of-scope-access.patch
+iommu-vt-d-avoid-null-pointer-dereference-or-refcount-corruption.patch
+drm-i915-skip-__i915_request_skip-for-already-signaled-requests.patch
+drm-panfrost-fix-wait_bo-ioctl-leaking-positive-return-from-dma_resv_wait_timeout.patch
+drm-xe-dma-buf-handle-empty-bo-and-uaf-races.patch
+drm-xe-dma-buf-fix-uaf-with-retry-loop.patch
+drm-ttm-convert-eagain-from-dmem_cgroup_try_charge-to-enospc.patch
--- /dev/null
+From 7d9a7f1f96cd617ee9e75bb22217c709038e26b8 Mon Sep 17 00:00:00 2001
+From: Ye Bin <yebin10@huawei.com>
+Date: Thu, 14 May 2026 21:14:18 +0800
+Subject: smb/client: fix possible infinite loop and oob read in symlink_data()
+
+From: Ye Bin <yebin10@huawei.com>
+
+commit 7d9a7f1f96cd617ee9e75bb22217c709038e26b8 upstream.
+
+On 32-bit architectures, the infinite loop is as follows:
+
+ len = p->ErrorDataLength == 0xfffffff8
+ u8 *next = p->ErrorContextData + len
+ next == p
+
+On 32-bit architectures, the out-of-bounds read is as follows:
+
+ len = p->ErrorDataLength == 0xfffffff0
+ u8 *next = p->ErrorContextData + len
+ next == (u8 *)p - 8
+
+Reported-by: ChenXiaoSong <chenxiaosong@kylinos.cn>
+Fixes: 76894f3e2f71 ("cifs: improve symlink handling for smb2+")
+Cc: stable@vger.kernel.org
+Signed-off-by: Ye Bin <yebin10@huawei.com>
+Reviewed-by: ChenXiaoSong <chenxiaosong@kylinos.cn>
+Signed-off-by: Steve French <stfrench@microsoft.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/smb/client/smb2file.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/fs/smb/client/smb2file.c
++++ b/fs/smb/client/smb2file.c
+@@ -49,6 +49,9 @@ static struct smb2_symlink_err_rsp *syml
+ __func__, le32_to_cpu(p->ErrorId));
+
+ len = ALIGN(le32_to_cpu(p->ErrorDataLength), 8);
++ if (len > end - ((u8 *)p + sizeof(*p)))
++ return ERR_PTR(-EINVAL);
++
+ p = (struct smb2_error_context_rsp *)(p->ErrorContextData + len);
+ }
+ } else if (le32_to_cpu(err->ByteCount) >= sizeof(*sym) &&
--- /dev/null
+From 23e6a1ca04ae44806439a5a446e62e4d42e80bb4 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Carlos=20L=C3=B3pez?= <clopez@suse.de>
+Date: Tue, 12 May 2026 12:00:41 +0200
+Subject: virt: sev-guest: Do not use host-controlled page order in cleanup path
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Carlos López <clopez@suse.de>
+
+commit 23e6a1ca04ae44806439a5a446e62e4d42e80bb4 upstream.
+
+When issuing an extended guest request (SVM_VMGEXIT_EXT_GUEST_REQUEST),
+get_ext_report() allocates a buffer to retrieve a certificate blob from the
+host, keeping track of its size in report_req->certs_len.
+
+However, the host may return SNP_GUEST_VMM_ERR_INVALID_LEN, indicating
+an invalid buffer size, as well as the expected length of such buffer.
+get_ext_report() subsequently updates report_req->certs_len with the
+host-controlled value, and cleans up the buffer by computing a page order
+from such value. This is incorrect, as the host-provided length may not
+match the page order of the original allocation, potentially resulting
+in corruption in the page allocator.
+
+Fix this by using alloc_pages_exact() instead, and reusing @npages to
+compute the size passed to free_pages_exact(). For consistency, also
+use @npages to compute the size when allocating the pages, even though
+this last change has no functional effect.
+
+Fixes: 3e385c0d6ce8 ("virt: sev-guest: Move SNP Guest Request data pages handling under snp_cmd_mutex")
+Signed-off-by: Carlos López <clopez@suse.de>
+Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
+Tested-by: Michael Roth <michael.roth@amd.com>
+Cc: stable@kernel.org
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/virt/coco/sev-guest/sev-guest.c | 12 +++++-------
+ 1 file changed, 5 insertions(+), 7 deletions(-)
+
+--- a/drivers/virt/coco/sev-guest/sev-guest.c
++++ b/drivers/virt/coco/sev-guest/sev-guest.c
+@@ -176,7 +176,6 @@ static int get_ext_report(struct snp_gue
+ struct snp_guest_req req = {};
+ int ret, npages = 0, resp_len;
+ sockptr_t certs_address;
+- struct page *page;
+
+ if (sockptr_is_null(io->req_data) || sockptr_is_null(io->resp_data))
+ return -EINVAL;
+@@ -211,16 +210,15 @@ static int get_ext_report(struct snp_gue
+ * zeros to indicate that certificate data was not provided.
+ */
+ npages = report_req->certs_len >> PAGE_SHIFT;
+- page = alloc_pages(GFP_KERNEL_ACCOUNT | __GFP_ZERO,
+- get_order(report_req->certs_len));
+- if (!page)
++ req.certs_data = alloc_pages_exact(npages << PAGE_SHIFT,
++ GFP_KERNEL_ACCOUNT | __GFP_ZERO);
++ if (!req.certs_data)
+ return -ENOMEM;
+
+- req.certs_data = page_address(page);
+ ret = set_memory_decrypted((unsigned long)req.certs_data, npages);
+ if (ret) {
+ pr_err("failed to mark page shared, ret=%d\n", ret);
+- __free_pages(page, get_order(report_req->certs_len));
++ free_pages_exact(req.certs_data, npages << PAGE_SHIFT);
+ return -EFAULT;
+ }
+
+@@ -277,7 +275,7 @@ e_free_data:
+ if (set_memory_encrypted((unsigned long)req.certs_data, npages))
+ WARN_ONCE(ret, "failed to restore encryption mask (leak it)\n");
+ else
+- __free_pages(page, get_order(report_req->certs_len));
++ free_pages_exact(req.certs_data, npages << PAGE_SHIFT);
+ }
+ return ret;
+ }
--- /dev/null
+From 786a45757dcdf8f2beb9d4a6db605db16c18b2b4 Mon Sep 17 00:00:00 2001
+From: David Woodhouse <dwmw@amazon.co.uk>
+Date: Tue, 28 Apr 2026 21:59:52 +0100
+Subject: x86/kexec: Push kjump return address even for non-kjump kexec
+
+From: David Woodhouse <dwmw@amazon.co.uk>
+
+commit 786a45757dcdf8f2beb9d4a6db605db16c18b2b4 upstream.
+
+The version of purgatory code shipped by kexec-tools attempts to look above
+the top of its stack to find a return address for a kjump, even in a non-kjump
+kexec.
+
+After the commit in Fixes: the word above the stack might not be there,
+leading to a fault (which is at least now caught by my exception-handling code
+in kexec).
+
+That commit fixed things for the actual kjump path, but no longer
+"gratuitously" pushes the unused return address to the stack in the non-kjump
+path. Put that *back* in the non-kjump path, to prevent purgatory from
+crashing when trying to access it.
+
+Fixes: 2cacf7f23a02 ("x86/kexec: Fix stack and handling of re-entry point for ::preserve_context")
+Reported-by: Rohan Kakulawaram <rohanka@google.com>
+Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
+Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
+Acked-by: Dave Hansen <dave.hansen@linux.intel.com>
+Tested-by: Rohan Kakulawaram <rohanka@google.com>
+Cc: <stable@kernel.org>
+Link: https://patch.msgid.link/32d627134143ffd957891cb697138e839c623211.camel@infradead.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/x86/kernel/relocate_kernel_64.S | 8 ++++++++
+ 1 file changed, 8 insertions(+)
+
+--- a/arch/x86/kernel/relocate_kernel_64.S
++++ b/arch/x86/kernel/relocate_kernel_64.S
+@@ -133,6 +133,14 @@ SYM_CODE_START_LOCAL_NOALIGN(identity_ma
+ * %r13 original CR4 when relocate_kernel() was invoked
+ */
+
++ /*
++ * Set return address to 0 if not preserving context. The purgatory
++ * shipped in kexec-tools will unconditionally look for the return
++ * address on the stack and set a kexec_jump_back_entry= command
++ * line option if it's non-zero. There's no other way that it can
++ * tell a preserve-context (kjump) kexec from a normal one.
++ */
++ pushq $0
+ /* store the start address on the stack */
+ pushq %rdx
+
--- /dev/null
+From 592975da8c3ca87b043077e6eafa37665eae7936 Mon Sep 17 00:00:00 2001
+From: Wilfred Mallawa <wilfred.mallawa@wdc.com>
+Date: Wed, 15 Apr 2026 09:45:14 +1000
+Subject: xfs: fix memory leak on error in xfs_alloc_zone_info()
+
+From: Wilfred Mallawa <wilfred.mallawa@wdc.com>
+
+commit 592975da8c3ca87b043077e6eafa37665eae7936 upstream.
+
+Currently, the 0th index of the zi_used_bucket_bitmap array is not freed
+on error due to the pre-decrement then evaluate semantic of the while
+loop used in xfs_alloc_zone_info(). Fix it by allowing for the i == 0
+case to be covered.
+
+Fixes: 080d01c41d44 ("xfs: implement zoned garbage collection")
+Cc: stable@vger.kernel.org # v6.15
+Reviewed-by: Damien Le Moal <dlemoal@kernel.org>
+Reviewed-by: Carlos Maiolino <cmaiolino@redhat.com>
+Signed-off-by: Wilfred Mallawa <wilfred.mallawa@wdc.com>
+Reviewed-by: Hans Holmberg <hans.holmberg@wdc.com>
+Reviewed-by: Christoph Hellwig <hch@lst.de>
+Reviewed-by: Darrick J. Wong <djwong@kernel.org>
+Signed-off-by: Carlos Maiolino <cem@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/xfs/xfs_zone_alloc.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/fs/xfs/xfs_zone_alloc.c
++++ b/fs/xfs/xfs_zone_alloc.c
+@@ -1178,7 +1178,7 @@ xfs_alloc_zone_info(
+ return zi;
+
+ out_free_bitmaps:
+- while (--i > 0)
++ while (--i >= 0)
+ kvfree(zi->zi_used_bucket_bitmap[i]);
+ kfree(zi);
+ return NULL;
projects / thirdparty / kernel / stable-queue.git / commitdiff
