From: Greg Kroah-Hartman Date: Wed, 20 May 2026 15:01:23 +0000 (+0200) Subject: 6.18-stable patches X-Git-Tag: v6.6.141~45 X-Git-Url: http://git.ipfire.org/gitweb/index.cgi?a=commitdiff_plain;h=ebe9c2101ebe9b0822e2b5c788c8d206cb16fa4d;p=thirdparty%2Fkernel%2Fstable-queue.git 6.18-stable patches added patches: 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 drm-i915-dp-fix-vsc-dynamic-range-signaling-for-rgb-formats.patch drm-i915-skip-__i915_request_skip-for-already-signaled-requests.patch drm-loongson-use-managed-kms-polling.patch drm-panfrost-fix-wait_bo-ioctl-leaking-positive-return-from-dma_resv_wait_timeout.patch drm-replace-old-pointer-to-new-idr.patch drm-ttm-convert-eagain-from-dmem_cgroup_try_charge-to-enospc.patch drm-xe-dma-buf-fix-uaf-with-retry-loop.patch drm-xe-dma-buf-handle-empty-bo-and-uaf-races.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 iommu-vt-d-avoid-null-pointer-dereference-or-refcount-corruption.patch iommu-vt-d-disable-dmar-for-intel-q35-igfx.patch iommu-vt-d-fix-oops-due-to-out-of-scope-access.patch irqchip-gic-v5-allocate-its-parent-lpis-as-a-range.patch irqchip-gic-v5-move-lpi-allocation-into-the-lpi-domain.patch irqchip-gic-v5-support-range-allocation-for-lpis.patch irqchip-meson-gpio-use-the-correct-register-in-meson_s4_gpio_irq_set_type.patch irqchip-riscv-imsic-clear-interrupt-move-state-during-cpu-offlining.patch libceph-fix-potential-null-ptr-deref-in-decode_choose_args.patch libceph-fix-potential-out-of-bounds-access-in-crush_decode.patch libceph-fix-potential-out-of-bounds-access-in-osdmap_decode.patch libceph-handle-rbtree-insertion-error-in-decode_choose_args.patch netfs-fix-error-handling-in-netfs_extract_user_iter.patch nfsd-fix-file-change-detection-in-cb_getattr.patch nvme-apple-reset-q-sq_tail-during-queue-init.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 powerpc-warp-fix-error-handling-in-pika_dtm_thread.patch riscv-misaligned-make-enabling-delegation-depend-on-nonportable.patch smb-client-fix-possible-infinite-loop-and-oob-read-in-symlink_data.patch virt-sev-guest-do-not-use-host-controlled-page-order-in-cleanup-path.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 --- diff --git a/queue-6.18/accel-rocket-fix-prep_bo-ioctl-leaking-positive-return-from-dma_resv_wait_timeout.patch b/queue-6.18/accel-rocket-fix-prep_bo-ioctl-leaking-positive-return-from-dma_resv_wait_timeout.patch new file mode 100644 index 0000000000..afaf56f383 --- /dev/null +++ b/queue-6.18/accel-rocket-fix-prep_bo-ioctl-leaking-positive-return-from-dma_resv_wait_timeout.patch @@ -0,0 +1,38 @@ +From 74570e12b4705ea11dcdfbfbd0a0b0fdaeff3059 Mon Sep 17 00:00:00 2001 +From: Gyeyoung Baek +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 + +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 +Reviewed-by: Tomeu Vizoso +Link: https://patch.msgid.link/c0ebf83b345721701b22d8f5bc41c52c0ecf5e16.1776581974.git.gye976@gmail.com +Signed-off-by: Steven Price +Signed-off-by: Greg Kroah-Hartman +--- + 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; + diff --git a/queue-6.18/alsa-hda-realtek-add-mute-led-quirk-for-hp-pavilion-laptop-16-ag0xxx.patch b/queue-6.18/alsa-hda-realtek-add-mute-led-quirk-for-hp-pavilion-laptop-16-ag0xxx.patch new file mode 100644 index 0000000000..a0f9963ed9 --- /dev/null +++ b/queue-6.18/alsa-hda-realtek-add-mute-led-quirk-for-hp-pavilion-laptop-16-ag0xxx.patch @@ -0,0 +1,38 @@ +From 7d1051ad68df3d584b5f24bfa1fb19f3a24db278 Mon Sep 17 00:00:00 2001 +From: Adrien Burnett +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 + +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: +Signed-off-by: Adrien Burnett +Link: https://patch.msgid.link/20260514165905.21175-1-an.arctic.pigeon@gmail.com +Signed-off-by: Takashi Iwai +Signed-off-by: Greg Kroah-Hartman +--- + 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), diff --git a/queue-6.18/alsa-hda-realtek-add-quirk-for-samsung-galaxy-book5-360-headphone.patch b/queue-6.18/alsa-hda-realtek-add-quirk-for-samsung-galaxy-book5-360-headphone.patch new file mode 100644 index 0000000000..28a1cec9d1 --- /dev/null +++ b/queue-6.18/alsa-hda-realtek-add-quirk-for-samsung-galaxy-book5-360-headphone.patch @@ -0,0 +1,35 @@ +From fd87b510f5f543125ecf51e7c706a9f4bc3352be Mon Sep 17 00:00:00 2001 +From: Markus Kramer +Date: Thu, 14 May 2026 00:28:18 +0200 +Subject: ALSA: hda/realtek: Add quirk for Samsung Galaxy Book5 360 headphone + +From: Markus Kramer + +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 +Link: https://patch.msgid.link/20260513222818.14351-1-linux@markus-kramer.de +Signed-off-by: Takashi Iwai +Signed-off-by: Greg Kroah-Hartman +--- + 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), diff --git a/queue-6.18/alsa-usb-audio-bound-midi-2.0-endpoint-descriptor-scans.patch b/queue-6.18/alsa-usb-audio-bound-midi-2.0-endpoint-descriptor-scans.patch new file mode 100644 index 0000000000..08aa6d1270 --- /dev/null +++ b/queue-6.18/alsa-usb-audio-bound-midi-2.0-endpoint-descriptor-scans.patch @@ -0,0 +1,58 @@ +From 918be519c7876329e1b6e2ea1c59f0b75e792dca Mon Sep 17 00:00:00 2001 +From: =?UTF-8?q?C=C3=A1ssio=20Gabriel?= +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 + +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 +Link: https://patch.msgid.link/20260507-usb-midi-endpoint-scan-bounds-v1-2-329d7348160e@gmail.com +Signed-off-by: Takashi Iwai +Signed-off-by: Greg Kroah-Hartman +--- + 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; + } diff --git a/queue-6.18/alsa-usb-audio-bound-midi-endpoint-descriptor-scans.patch b/queue-6.18/alsa-usb-audio-bound-midi-endpoint-descriptor-scans.patch new file mode 100644 index 0000000000..6ca3ff7fbd --- /dev/null +++ b/queue-6.18/alsa-usb-audio-bound-midi-endpoint-descriptor-scans.patch @@ -0,0 +1,58 @@ +From d6854daa67be623860f4e1873fd3d3c275aba4ed Mon Sep 17 00:00:00 2001 +From: =?UTF-8?q?C=C3=A1ssio=20Gabriel?= +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 + +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 +Link: https://patch.msgid.link/20260507-usb-midi-endpoint-scan-bounds-v1-1-329d7348160e@gmail.com +Signed-off-by: Takashi Iwai +Signed-off-by: Greg Kroah-Hartman +--- + 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; + } diff --git a/queue-6.18/alsa-usb-audio-qcom-check-offload-mapping-failures.patch b/queue-6.18/alsa-usb-audio-qcom-check-offload-mapping-failures.patch new file mode 100644 index 0000000000..0af691690c --- /dev/null +++ b/queue-6.18/alsa-usb-audio-qcom-check-offload-mapping-failures.patch @@ -0,0 +1,108 @@ +From 814b2c9b30e56074e11fc0a6e5419b3fee0639bc Mon Sep 17 00:00:00 2001 +From: =?UTF-8?q?C=C3=A1ssio=20Gabriel?= +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 + +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 +Link: https://patch.msgid.link/20260511-alsa-usb-qcom-offload-map-errors-v1-1-6502695e58bc@gmail.com +Signed-off-by: Takashi Iwai +Signed-off-by: Greg Kroah-Hartman +--- + 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; diff --git a/queue-6.18/btrfs-only-release-the-dirty-pages-io-tree-after-successful-writes.patch b/queue-6.18/btrfs-only-release-the-dirty-pages-io-tree-after-successful-writes.patch new file mode 100644 index 0000000000..c97afdc8b5 --- /dev/null +++ b/queue-6.18/btrfs-only-release-the-dirty-pages-io-tree-after-successful-writes.patch @@ -0,0 +1,152 @@ +From 4066c55e109475a06d18a1f127c939d551211956 Mon Sep 17 00:00:00 2001 +From: Qu Wenruo +Date: Thu, 30 Apr 2026 10:37:22 +0930 +Subject: btrfs: only release the dirty pages io tree after successful writes + +From: Qu Wenruo + +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: + + 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 + + ---[ 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 +Signed-off-by: Qu Wenruo +Signed-off-by: David Sterba +Signed-off-by: Greg Kroah-Hartman +--- + 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; + } + + /* diff --git a/queue-6.18/ceph-fix-a-buffer-leak-in-__ceph_setxattr.patch b/queue-6.18/ceph-fix-a-buffer-leak-in-__ceph_setxattr.patch new file mode 100644 index 0000000000..5b0c0e1c63 --- /dev/null +++ b/queue-6.18/ceph-fix-a-buffer-leak-in-__ceph_setxattr.patch @@ -0,0 +1,34 @@ +From 5d3cc36b4e77a27ce7b686b7c59c7072bcb3fa8e Mon Sep 17 00:00:00 2001 +From: Viacheslav Dubeyko +Date: Thu, 9 Apr 2026 12:26:02 -0700 +Subject: ceph: fix a buffer leak in __ceph_setxattr() + +From: Viacheslav Dubeyko + +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 +Reviewed-by: Alex Markuze +Signed-off-by: Ilya Dryomov +Signed-off-by: Greg Kroah-Hartman +--- + 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); diff --git a/queue-6.18/ceph-fix-bug_on-in-__ceph_build_xattrs_blob-due-to-stale-blob-size.patch b/queue-6.18/ceph-fix-bug_on-in-__ceph_build_xattrs_blob-due-to-stale-blob-size.patch new file mode 100644 index 0000000000..ef9f373711 --- /dev/null +++ b/queue-6.18/ceph-fix-bug_on-in-__ceph_build_xattrs_blob-due-to-stale-blob-size.patch @@ -0,0 +1,125 @@ +From 0c22d9511cbde746622f8e4c11aaa63fe76d45f9 Mon Sep 17 00:00:00 2001 +From: Viacheslav Dubeyko +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 + +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] +[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] +[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 +Reviewed-by: Alex Markuze +Signed-off-by: Ilya Dryomov +Signed-off-by: Greg Kroah-Hartman +--- + 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; diff --git a/queue-6.18/drm-i915-dp-fix-vsc-dynamic-range-signaling-for-rgb-formats.patch b/queue-6.18/drm-i915-dp-fix-vsc-dynamic-range-signaling-for-rgb-formats.patch new file mode 100644 index 0000000000..dda900c966 --- /dev/null +++ b/queue-6.18/drm-i915-dp-fix-vsc-dynamic-range-signaling-for-rgb-formats.patch @@ -0,0 +1,55 @@ +From 1ae15b6c7965d137eef21f2cc7d367b29cb88369 Mon Sep 17 00:00:00 2001 +From: Chaitanya Kumar Borah +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 + +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 +Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/work_items/15874 +Tested-by: DeepChirp +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 +Reviewed-by: Suraj Kandpal +Signed-off-by: Suraj Kandpal +Link: https://patch.msgid.link/20260505090920.2479112-1-chaitanya.kumar.borah@intel.com +(cherry picked from commit 38e10ddae6f8d42a2e8437fcd25a1cac51106c64) +Signed-off-by: Tvrtko Ursulin +Signed-off-by: Greg Kroah-Hartman +--- + 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; + } + diff --git a/queue-6.18/drm-i915-skip-__i915_request_skip-for-already-signaled-requests.patch b/queue-6.18/drm-i915-skip-__i915_request_skip-for-already-signaled-requests.patch new file mode 100644 index 0000000000..a44605ce65 --- /dev/null +++ b/queue-6.18/drm-i915-skip-__i915_request_skip-for-already-signaled-requests.patch @@ -0,0 +1,61 @@ +From 4cfe4c0efbdcde742a47813180cc69b132d7598e Mon Sep 17 00:00:00 2001 +From: Sebastian Brzezinka +Date: Thu, 16 Apr 2026 13:31:18 +0200 +Subject: drm/i915: skip __i915_request_skip() for already signaled requests + +From: Sebastian Brzezinka + +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 +Cc: stable@vger.kernel.org # v5.7+ +Reviewed-by: Krzysztof Karas +Reviewed-by: Andi Shyti +Signed-off-by: Andi Shyti +Link: https://lore.kernel.org/r/fe76921d35b6ae85aa651822726d0d9815aa5362.1776339012.git.sebastian.brzezinka@intel.com +(cherry picked from commit 5ba54393dcd7adf75a9f39f5a933b1538349cad5) +Signed-off-by: Tvrtko Ursulin +Signed-off-by: Greg Kroah-Hartman +--- + 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); diff --git a/queue-6.18/drm-loongson-use-managed-kms-polling.patch b/queue-6.18/drm-loongson-use-managed-kms-polling.patch new file mode 100644 index 0000000000..e97d41adfd --- /dev/null +++ b/queue-6.18/drm-loongson-use-managed-kms-polling.patch @@ -0,0 +1,46 @@ +From 0a9c56dd387605d17dabeedd9fdd2c4c1d0bab7b Mon Sep 17 00:00:00 2001 +From: Myeonghun Pak +Date: Wed, 13 May 2026 15:57:00 +0900 +Subject: drm/loongson: Use managed KMS polling + +From: Myeonghun Pak + +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 +Signed-off-by: Ijae Kim +Reviewed-by: Thomas Zimmermann +Acked-by: Jianmin Lv +Reviewed-by: Huacai Chen +Signed-off-by: Myeonghun Pak +Signed-off-by: Thomas Zimmermann +Link: https://patch.msgid.link/20260513065706.23803-1-mhun512@gmail.com +Signed-off-by: Greg Kroah-Hartman +--- + 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); diff --git a/queue-6.18/drm-panfrost-fix-wait_bo-ioctl-leaking-positive-return-from-dma_resv_wait_timeout.patch b/queue-6.18/drm-panfrost-fix-wait_bo-ioctl-leaking-positive-return-from-dma_resv_wait_timeout.patch new file mode 100644 index 0000000000..20303216d4 --- /dev/null +++ b/queue-6.18/drm-panfrost-fix-wait_bo-ioctl-leaking-positive-return-from-dma_resv_wait_timeout.patch @@ -0,0 +1,43 @@ +From 459d75523b71c0ec254d153d8850d0b7008af396 Mon Sep 17 00:00:00 2001 +From: Gyeyoung Baek +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 + +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 +Reviewed-by: Adrián Larumbe +Reviewed-by: Boris Brezillon +Reviewed-by: Steven Price +Link: https://patch.msgid.link/fe33f82fded7be1c18e2e0eb2db451d5a738cf39.1776581974.git.gye976@gmail.com +Signed-off-by: Steven Price +Signed-off-by: Greg Kroah-Hartman +--- + 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); + diff --git a/queue-6.18/drm-replace-old-pointer-to-new-idr.patch b/queue-6.18/drm-replace-old-pointer-to-new-idr.patch new file mode 100644 index 0000000000..6baaf143fe --- /dev/null +++ b/queue-6.18/drm-replace-old-pointer-to-new-idr.patch @@ -0,0 +1,72 @@ +From dc366607c41c45fd0ae6f3db090f31dd611b644a Mon Sep 17 00:00:00 2001 +From: Edward Adam Davis +Date: Wed, 13 May 2026 12:30:50 +0800 +Subject: drm: Replace old pointer to new idr + +From: Edward Adam Davis + +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 +Signed-off-by: Dave Airlie +Link: https://patch.msgid.link/tencent_C267296443AAA4567771176886DFF364A305@qq.com +Signed-off-by: Greg Kroah-Hartman +--- + 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); diff --git a/queue-6.18/drm-ttm-convert-eagain-from-dmem_cgroup_try_charge-to-enospc.patch b/queue-6.18/drm-ttm-convert-eagain-from-dmem_cgroup_try_charge-to-enospc.patch new file mode 100644 index 0000000000..ad94cbfbb6 --- /dev/null +++ b/queue-6.18/drm-ttm-convert-eagain-from-dmem_cgroup_try_charge-to-enospc.patch @@ -0,0 +1,67 @@ +From 591711b32681a04b57d00c2a404658f8419a081c Mon Sep 17 00:00:00 2001 +From: =?UTF-8?q?Thomas=20Hellstr=C3=B6m?= +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 + +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 +Cc: Maarten Lankhorst +Cc: Tejun Heo +Cc: Maxime Ripard +Cc: Christian Koenig +Cc: dri-devel@lists.freedesktop.org +Cc: # 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 +Reviewed-by: Maarten Lankhorst +Link: https://patch.msgid.link/20260508160920.230339-1-thomas.hellstrom@linux.intel.com +Signed-off-by: Greg Kroah-Hartman +--- + 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); diff --git a/queue-6.18/drm-xe-dma-buf-fix-uaf-with-retry-loop.patch b/queue-6.18/drm-xe-dma-buf-fix-uaf-with-retry-loop.patch new file mode 100644 index 0000000000..5d18fbb04c --- /dev/null +++ b/queue-6.18/drm-xe-dma-buf-fix-uaf-with-retry-loop.patch @@ -0,0 +1,139 @@ +From 155a372a1cc50fa93387c5d3cdfd614a61e1afd1 Mon Sep 17 00:00:00 2001 +From: Matthew Auld +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 + +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 +Cc: Thomas Hellström +Cc: Matthew Brost +Cc: # v6.18+ +Reviewed-by: Thomas Hellström +Link: https://patch.msgid.link/20260508102635.149172-4-matthew.auld@intel.com +(cherry picked from commit 479669418253e0f27f8cf5db01a731352ea592e7) +Signed-off-by: Rodrigo Vivi +Signed-off-by: Greg Kroah-Hartman +--- + 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) diff --git a/queue-6.18/drm-xe-dma-buf-handle-empty-bo-and-uaf-races.patch b/queue-6.18/drm-xe-dma-buf-handle-empty-bo-and-uaf-races.patch new file mode 100644 index 0000000000..70c729f334 --- /dev/null +++ b/queue-6.18/drm-xe-dma-buf-handle-empty-bo-and-uaf-races.patch @@ -0,0 +1,117 @@ +From 981bedbbe61364fcc3a3b87ebaf648a66cd07108 Mon Sep 17 00:00:00 2001 +From: Matthew Auld +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 + +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 +Cc: Thomas Hellström +Cc: Matthew Brost +Cc: # v6.8+ +Reviewed-by: Matthew Brost +Acked-by: Thomas Hellström +Link: https://patch.msgid.link/20260508102635.149172-3-matthew.auld@intel.com +(cherry picked from commit af1f2ad0c59fe4e2f924c526f66e968289d77971) +Signed-off-by: Rodrigo Vivi +Signed-off-by: Greg Kroah-Hartman +--- + 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; + } diff --git a/queue-6.18/io-wq-check-that-the-predecessor-is-hashed-in-io_wq_remove_pending.patch b/queue-6.18/io-wq-check-that-the-predecessor-is-hashed-in-io_wq_remove_pending.patch new file mode 100644 index 0000000000..6fe805bf34 --- /dev/null +++ b/queue-6.18/io-wq-check-that-the-predecessor-is-hashed-in-io_wq_remove_pending.patch @@ -0,0 +1,52 @@ +From d6a2d7b04b5a093021a7a0e2e69e9d5237dfa8cc Mon Sep 17 00:00:00 2001 +From: Nicholas Carlini +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 + +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 +Signed-off-by: Jens Axboe +Signed-off-by: Greg Kroah-Hartman +--- + 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; diff --git a/queue-6.18/iommu-amd-bounds-check-devid-in-__rlookup_amd_iommu.patch b/queue-6.18/iommu-amd-bounds-check-devid-in-__rlookup_amd_iommu.patch new file mode 100644 index 0000000000..56c561c94a --- /dev/null +++ b/queue-6.18/iommu-amd-bounds-check-devid-in-__rlookup_amd_iommu.patch @@ -0,0 +1,82 @@ +From 07d0f496fe7ec5abe3bee7e38be709521567bb33 Mon Sep 17 00:00:00 2001 +From: "Jose Fernandez (Anthropic)" +Date: Tue, 21 Apr 2026 19:26:13 +0000 +Subject: iommu/amd: Bounds-check devid in __rlookup_amd_iommu() + +From: Jose Fernandez (Anthropic) + +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 +Tested-by: Ziyuan Chen +Reviewed-by: Josef Bacik +Assisted-by: Claude:unspecified +Signed-off-by: Jose Fernandez (Anthropic) +Signed-off-by: Joerg Roedel +Signed-off-by: Greg Kroah-Hartman +--- + 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; + } diff --git a/queue-6.18/iommu-vt-d-avoid-null-pointer-dereference-or-refcount-corruption.patch b/queue-6.18/iommu-vt-d-avoid-null-pointer-dereference-or-refcount-corruption.patch new file mode 100644 index 0000000000..e15755d2d3 --- /dev/null +++ b/queue-6.18/iommu-vt-d-avoid-null-pointer-dereference-or-refcount-corruption.patch @@ -0,0 +1,63 @@ +From 79ea2feb917b05366b49d85573c9c5331f043b2c Mon Sep 17 00:00:00 2001 +From: Zhenzhong Duan +Date: Sat, 9 May 2026 10:43:46 +0800 +Subject: iommu/vt-d: Avoid NULL pointer dereference or refcount corruption + +From: Zhenzhong Duan + +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 +Signed-off-by: Zhenzhong Duan +Reviewed-by: Kevin Tian +Link: https://lore.kernel.org/r/20260422033538.95000-1-zhenzhong.duan@intel.com +Signed-off-by: Lu Baolu +Signed-off-by: Joerg Roedel +Signed-off-by: Greg Kroah-Hartman +--- + 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, diff --git a/queue-6.18/iommu-vt-d-disable-dmar-for-intel-q35-igfx.patch b/queue-6.18/iommu-vt-d-disable-dmar-for-intel-q35-igfx.patch new file mode 100644 index 0000000000..4b5a6f8592 --- /dev/null +++ b/queue-6.18/iommu-vt-d-disable-dmar-for-intel-q35-igfx.patch @@ -0,0 +1,47 @@ +From 2cda2e10dc8343ae01eae9e999a876b7e7d37861 Mon Sep 17 00:00:00 2001 +From: =?UTF-8?q?Naval=20Alcal=C3=A1?= +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á + +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á +Link: https://lore.kernel.org/r/20260410161622.13549-1-ari@naval.cat +Signed-off-by: Lu Baolu +Signed-off-by: Joerg Roedel +Signed-off-by: Greg Kroah-Hartman +--- + 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); diff --git a/queue-6.18/iommu-vt-d-fix-oops-due-to-out-of-scope-access.patch b/queue-6.18/iommu-vt-d-fix-oops-due-to-out-of-scope-access.patch new file mode 100644 index 0000000000..f696b571fa --- /dev/null +++ b/queue-6.18/iommu-vt-d-fix-oops-due-to-out-of-scope-access.patch @@ -0,0 +1,66 @@ +From a6dea58d8625c06b9654c0555f101742481335c3 Mon Sep 17 00:00:00 2001 +From: Zhenzhong Duan +Date: Sat, 9 May 2026 10:43:45 +0800 +Subject: iommu/vt-d: Fix oops due to out of scope access + +From: Zhenzhong Duan + +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: + + 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 +Reviewed-by: Kevin Tian +Link: https://lore.kernel.org/r/20260421031347.1408890-1-zhenzhong.duan@intel.com +Signed-off-by: Lu Baolu +Signed-off-by: Joerg Roedel +Signed-off-by: Greg Kroah-Hartman +--- + 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); diff --git a/queue-6.18/irqchip-gic-v5-allocate-its-parent-lpis-as-a-range.patch b/queue-6.18/irqchip-gic-v5-allocate-its-parent-lpis-as-a-range.patch new file mode 100644 index 0000000000..f69690bae1 --- /dev/null +++ b/queue-6.18/irqchip-gic-v5-allocate-its-parent-lpis-as-a-range.patch @@ -0,0 +1,94 @@ +From a7c7e42654b6a8676610ee09d22901432c4851af Mon Sep 17 00:00:00 2001 +From: Sascha Bischoff +Date: Wed, 6 May 2026 09:37:43 +0000 +Subject: irqchip/gic-v5: Allocate ITS parent LPIs as a range + +From: Sascha Bischoff + +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 +Signed-off-by: Thomas Gleixner +Reviewed-by: Marc Zyngier +Reviewed-by: Lorenzo Pieralisi +Cc: stable@vger.kernel.org +Link: https://patch.msgid.link/20260506093634.382062-4-sascha.bischoff@arm.com +Signed-off-by: Greg Kroah-Hartman +--- + 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(); + } diff --git a/queue-6.18/irqchip-gic-v5-move-lpi-allocation-into-the-lpi-domain.patch b/queue-6.18/irqchip-gic-v5-move-lpi-allocation-into-the-lpi-domain.patch new file mode 100644 index 0000000000..773963a8d6 --- /dev/null +++ b/queue-6.18/irqchip-gic-v5-move-lpi-allocation-into-the-lpi-domain.patch @@ -0,0 +1,209 @@ +From dec85d2fbd20de3711a71e65397dfdb40c3fa953 Mon Sep 17 00:00:00 2001 +From: Sascha Bischoff +Date: Wed, 6 May 2026 09:37:02 +0000 +Subject: irqchip/gic-v5: Move LPI allocation into the LPI domain + +From: Sascha Bischoff + +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 +Signed-off-by: Thomas Gleixner +Reviewed-by: Marc Zyngier +Reviewed-by: Lorenzo Pieralisi +Cc: stable@vger.kernel.org +Link: https://patch.msgid.link/20260506093634.382062-2-sascha.bischoff@arm.com +Signed-off-by: Greg Kroah-Hartman +--- + 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 diff --git a/queue-6.18/irqchip-gic-v5-support-range-allocation-for-lpis.patch b/queue-6.18/irqchip-gic-v5-support-range-allocation-for-lpis.patch new file mode 100644 index 0000000000..af001e6b9e --- /dev/null +++ b/queue-6.18/irqchip-gic-v5-support-range-allocation-for-lpis.patch @@ -0,0 +1,161 @@ +From eb6f6d523813ead9dc2799194a2839d42c049734 Mon Sep 17 00:00:00 2001 +From: Sascha Bischoff +Date: Wed, 6 May 2026 09:37:23 +0000 +Subject: irqchip/gic-v5: Support range allocation for LPIs + +From: Sascha Bischoff + +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 +Signed-off-by: Thomas Gleixner +Reviewed-by: Marc Zyngier +Reviewed-by: Lorenzo Pieralisi +Cc: stable@vger.kernel.org +Link: https://patch.msgid.link/20260506093634.382062-3-sascha.bischoff@arm.com +Signed-off-by: Greg Kroah-Hartman +--- + 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 = { diff --git a/queue-6.18/irqchip-meson-gpio-use-the-correct-register-in-meson_s4_gpio_irq_set_type.patch b/queue-6.18/irqchip-meson-gpio-use-the-correct-register-in-meson_s4_gpio_irq_set_type.patch new file mode 100644 index 0000000000..4f6dc9a793 --- /dev/null +++ b/queue-6.18/irqchip-meson-gpio-use-the-correct-register-in-meson_s4_gpio_irq_set_type.patch @@ -0,0 +1,37 @@ +From 5363b67ac8ebcc3e227dbf59fc8061949109841d Mon Sep 17 00:00:00 2001 +From: Xianwei Zhao +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 + +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 +Signed-off-by: Thomas Gleixner +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 +--- + 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; + }; + diff --git a/queue-6.18/irqchip-riscv-imsic-clear-interrupt-move-state-during-cpu-offlining.patch b/queue-6.18/irqchip-riscv-imsic-clear-interrupt-move-state-during-cpu-offlining.patch new file mode 100644 index 0000000000..8835150fd0 --- /dev/null +++ b/queue-6.18/irqchip-riscv-imsic-clear-interrupt-move-state-during-cpu-offlining.patch @@ -0,0 +1,53 @@ +From cefafbd561402b0fe6447449364a30315b9b1570 Mon Sep 17 00:00:00 2001 +From: Yong-Xuan Wang +Date: Fri, 8 May 2026 02:31:21 -0700 +Subject: irqchip/riscv-imsic: Clear interrupt move state during CPU offlining + +From: Yong-Xuan Wang + +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 +Signed-off-by: Thomas Gleixner +Cc: stable@vger.kernel.org +Link: https://patch.msgid.link/20260508-imsic-v2-1-e9f08dd46cf5@sifive.com +Signed-off-by: Greg Kroah-Hartman +--- + 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(); + diff --git a/queue-6.18/libceph-fix-potential-null-ptr-deref-in-decode_choose_args.patch b/queue-6.18/libceph-fix-potential-null-ptr-deref-in-decode_choose_args.patch new file mode 100644 index 0000000000..7a64c772f7 --- /dev/null +++ b/queue-6.18/libceph-fix-potential-null-ptr-deref-in-decode_choose_args.patch @@ -0,0 +1,47 @@ +From 28b0a2ab8c82d0bbdeb8013029c67c978ce6e4bf Mon Sep 17 00:00:00 2001 +From: Raphael Zimmer +Date: Tue, 12 May 2026 18:16:40 +0200 +Subject: libceph: Fix potential null-ptr-deref in decode_choose_args() + +From: Raphael Zimmer + +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 +Reviewed-by: Ilya Dryomov +Signed-off-by: Ilya Dryomov +Signed-off-by: Greg Kroah-Hartman +--- + 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; + } + diff --git a/queue-6.18/libceph-fix-potential-out-of-bounds-access-in-crush_decode.patch b/queue-6.18/libceph-fix-potential-out-of-bounds-access-in-crush_decode.patch new file mode 100644 index 0000000000..d332361d16 --- /dev/null +++ b/queue-6.18/libceph-fix-potential-out-of-bounds-access-in-crush_decode.patch @@ -0,0 +1,98 @@ +From 4c79fc2d598694bda845b46229c9d48b65042970 Mon Sep 17 00:00:00 2001 +From: Raphael Zimmer +Date: Wed, 22 Apr 2026 10:47:13 +0200 +Subject: libceph: Fix potential out-of-bounds access in crush_decode() + +From: Raphael Zimmer + +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 +Reviewed-by: Ilya Dryomov +Signed-off-by: Ilya Dryomov +Signed-off-by: Greg Kroah-Hartman +--- + 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); diff --git a/queue-6.18/libceph-fix-potential-out-of-bounds-access-in-osdmap_decode.patch b/queue-6.18/libceph-fix-potential-out-of-bounds-access-in-osdmap_decode.patch new file mode 100644 index 0000000000..ceb90d1ac8 --- /dev/null +++ b/queue-6.18/libceph-fix-potential-out-of-bounds-access-in-osdmap_decode.patch @@ -0,0 +1,41 @@ +From 35d0ed82d03e5ee77ea4f31f20e29562a7721649 Mon Sep 17 00:00:00 2001 +From: Raphael Zimmer +Date: Tue, 5 May 2026 11:08:12 +0200 +Subject: libceph: Fix potential out-of-bounds access in osdmap_decode() + +From: Raphael Zimmer + +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 +Reviewed-by: Ilya Dryomov +Signed-off-by: Ilya Dryomov +Signed-off-by: Greg Kroah-Hartman +--- + 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; + diff --git a/queue-6.18/libceph-handle-rbtree-insertion-error-in-decode_choose_args.patch b/queue-6.18/libceph-handle-rbtree-insertion-error-in-decode_choose_args.patch new file mode 100644 index 0000000000..da149f5706 --- /dev/null +++ b/queue-6.18/libceph-handle-rbtree-insertion-error-in-decode_choose_args.patch @@ -0,0 +1,48 @@ +From d289478cfc0bcf81c7914200d6abdcb78bd04ded Mon Sep 17 00:00:00 2001 +From: Raphael Zimmer +Date: Tue, 12 May 2026 09:29:30 +0200 +Subject: libceph: handle rbtree insertion error in decode_choose_args() + +From: Raphael Zimmer + +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 +Reviewed-by: Ilya Dryomov +Signed-off-by: Ilya Dryomov +Signed-off-by: Greg Kroah-Hartman +--- + 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; diff --git a/queue-6.18/netfs-fix-error-handling-in-netfs_extract_user_iter.patch b/queue-6.18/netfs-fix-error-handling-in-netfs_extract_user_iter.patch new file mode 100644 index 0000000000..bcb36f14ef --- /dev/null +++ b/queue-6.18/netfs-fix-error-handling-in-netfs_extract_user_iter.patch @@ -0,0 +1,67 @@ +From 0aad5704c6b4d14007d4eab15883e8524e4310f4 Mon Sep 17 00:00:00 2001 +From: Paulo Alcantara +Date: Tue, 12 May 2026 13:33:46 +0100 +Subject: netfs: fix error handling in netfs_extract_user_iter() + +From: Paulo Alcantara + +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 +Signed-off-by: Paulo Alcantara (Red Hat) +Signed-off-by: David Howells +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 +Signed-off-by: Greg Kroah-Hartman +--- + 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; + } diff --git a/queue-6.18/nfsd-fix-file-change-detection-in-cb_getattr.patch b/queue-6.18/nfsd-fix-file-change-detection-in-cb_getattr.patch new file mode 100644 index 0000000000..8776885a63 --- /dev/null +++ b/queue-6.18/nfsd-fix-file-change-detection-in-cb_getattr.patch @@ -0,0 +1,77 @@ +From 304d81a2fbf2b454def4debcb38ea173911b72cd Mon Sep 17 00:00:00 2001 +From: Scott Mayhew +Date: Tue, 7 Apr 2026 18:08:57 -0400 +Subject: nfsd: fix file change detection in CB_GETATTR + +From: Scott Mayhew + +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 +Signed-off-by: Chuck Lever +Signed-off-by: Greg Kroah-Hartman +--- + 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; + diff --git a/queue-6.18/nvme-apple-reset-q-sq_tail-during-queue-init.patch b/queue-6.18/nvme-apple-reset-q-sq_tail-during-queue-init.patch new file mode 100644 index 0000000000..50cb39f307 --- /dev/null +++ b/queue-6.18/nvme-apple-reset-q-sq_tail-during-queue-init.patch @@ -0,0 +1,35 @@ +From a6ab75639e23169a741b0b2e12191fd8acb32c73 Mon Sep 17 00:00:00 2001 +From: Nick Chan +Date: Thu, 14 May 2026 21:16:01 +0800 +Subject: nvme-apple: Reset q->sq_tail during queue init + +From: Nick Chan + +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 +Reviewed-by: Sven Peter +Signed-off-by: Nick Chan +Signed-off-by: Keith Busch +Signed-off-by: Greg Kroah-Hartman +--- + 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) diff --git a/queue-6.18/platform-x86-intel-move-debugfs-register-before-creating-devices.patch b/queue-6.18/platform-x86-intel-move-debugfs-register-before-creating-devices.patch new file mode 100644 index 0000000000..d69890a1f7 --- /dev/null +++ b/queue-6.18/platform-x86-intel-move-debugfs-register-before-creating-devices.patch @@ -0,0 +1,55 @@ +From ad3bff944c0f4f2e913298a9664391af32f87491 Mon Sep 17 00:00:00 2001 +From: Srinivas Pandruvada +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 + +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 +Cc: Stable@vger.kernel.org +Link: https://patch.msgid.link/20260430151103.1549733-2-srinivas.pandruvada@linux.intel.com +Reviewed-by: Ilpo Järvinen +Signed-off-by: Ilpo Järvinen +Signed-off-by: Greg Kroah-Hartman +--- + 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; + } + diff --git a/queue-6.18/platform-x86-lenovo-wmi-helpers-move-gamezone-enums-to-wmi-helpers.patch b/queue-6.18/platform-x86-lenovo-wmi-helpers-move-gamezone-enums-to-wmi-helpers.patch new file mode 100644 index 0000000000..07a2704cdf --- /dev/null +++ b/queue-6.18/platform-x86-lenovo-wmi-helpers-move-gamezone-enums-to-wmi-helpers.patch @@ -0,0 +1,119 @@ +From 7e27896e16a1c450085c3fe020eeb1b223880f37 Mon Sep 17 00:00:00 2001 +From: "Derek J. Clark" +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 + +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 +Reviewed-by: Rong Zhang +Tested-by: Rong Zhang +Signed-off-by: Derek J. Clark +Link: https://patch.msgid.link/20260510042546.436874-8-derekjohn.clark@gmail.com +Reviewed-by: Ilpo Järvinen +Signed-off-by: Ilpo Järvinen +Signed-off-by: Greg Kroah-Hartman +--- + 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 + + #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 + + #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 */ +- +-#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" diff --git a/queue-6.18/platform-x86-lenovo-wmi-other-fix-tunable_attr_01-struct-members.patch b/queue-6.18/platform-x86-lenovo-wmi-other-fix-tunable_attr_01-struct-members.patch new file mode 100644 index 0000000000..5e933982e6 --- /dev/null +++ b/queue-6.18/platform-x86-lenovo-wmi-other-fix-tunable_attr_01-struct-members.patch @@ -0,0 +1,48 @@ +From 71f3843e0f81e3c097a088c1121154bb9a44da0a Mon Sep 17 00:00:00 2001 +From: "Derek J. Clark" +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 + +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 +Cc: stable@vger.kernel.org +Reviewed-by: Rong Zhang +Tested-by: Rong Zhang +Signed-off-by: Derek J. Clark +Link: https://patch.msgid.link/20260510042546.436874-6-derekjohn.clark@gmail.com +Reviewed-by: Ilpo Järvinen +Signed-off-by: Ilpo Järvinen +Signed-off-by: Greg Kroah-Hartman +--- + 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 = { diff --git a/queue-6.18/powerpc-warp-fix-error-handling-in-pika_dtm_thread.patch b/queue-6.18/powerpc-warp-fix-error-handling-in-pika_dtm_thread.patch new file mode 100644 index 0000000000..a46dda1334 --- /dev/null +++ b/queue-6.18/powerpc-warp-fix-error-handling-in-pika_dtm_thread.patch @@ -0,0 +1,39 @@ +From 108d7f951271cbd36ca36efc5e5d106966f5180c Mon Sep 17 00:00:00 2001 +From: Ma Ke +Date: Sun, 16 Nov 2025 10:44:11 +0800 +Subject: powerpc/warp: Fix error handling in pika_dtm_thread + +From: Ma Ke + +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 +Reviewed-by: Christophe Leroy +Signed-off-by: Madhavan Srinivasan +Link: https://patch.msgid.link/20251116024411.21968-1-make24@iscas.ac.cn +Signed-off-by: Greg Kroah-Hartman +--- + 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; + } + diff --git a/queue-6.18/riscv-misaligned-make-enabling-delegation-depend-on-nonportable.patch b/queue-6.18/riscv-misaligned-make-enabling-delegation-depend-on-nonportable.patch new file mode 100644 index 0000000000..d6e024ce33 --- /dev/null +++ b/queue-6.18/riscv-misaligned-make-enabling-delegation-depend-on-nonportable.patch @@ -0,0 +1,83 @@ +From b69bcb13ed7024a84d6cd8ad330f1e32782fcf28 Mon Sep 17 00:00:00 2001 +From: Vivian Wang +Date: Wed, 1 Apr 2026 09:53:17 +0800 +Subject: riscv: misaligned: Make enabling delegation depend on NONPORTABLE + +From: Vivian Wang + +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 # 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 +Acked-by: Conor Dooley +Link: https://patch.msgid.link/20260401-riscv-misaligned-dont-delegate-v2-1-5014a288c097@iscas.ac.cn +Signed-off-by: Paul Walmsley +Signed-off-by: Greg Kroah-Hartman +--- + 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) + { diff --git a/queue-6.18/series b/queue-6.18/series index bb3ebab6d1..b777c89e3b 100644 --- a/queue-6.18/series +++ b/queue-6.18/series @@ -899,3 +899,46 @@ fuse-avoid-0x10-fault-in-fuse_readahead-when-max_pag.patch 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 diff --git a/queue-6.18/smb-client-fix-possible-infinite-loop-and-oob-read-in-symlink_data.patch b/queue-6.18/smb-client-fix-possible-infinite-loop-and-oob-read-in-symlink_data.patch new file mode 100644 index 0000000000..0d5bc4b561 --- /dev/null +++ b/queue-6.18/smb-client-fix-possible-infinite-loop-and-oob-read-in-symlink_data.patch @@ -0,0 +1,44 @@ +From 7d9a7f1f96cd617ee9e75bb22217c709038e26b8 Mon Sep 17 00:00:00 2001 +From: Ye Bin +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 + +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 +Fixes: 76894f3e2f71 ("cifs: improve symlink handling for smb2+") +Cc: stable@vger.kernel.org +Signed-off-by: Ye Bin +Reviewed-by: ChenXiaoSong +Signed-off-by: Steve French +Signed-off-by: Greg Kroah-Hartman +--- + 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) && diff --git a/queue-6.18/virt-sev-guest-do-not-use-host-controlled-page-order-in-cleanup-path.patch b/queue-6.18/virt-sev-guest-do-not-use-host-controlled-page-order-in-cleanup-path.patch new file mode 100644 index 0000000000..f00d6a5233 --- /dev/null +++ b/queue-6.18/virt-sev-guest-do-not-use-host-controlled-page-order-in-cleanup-path.patch @@ -0,0 +1,80 @@ +From 23e6a1ca04ae44806439a5a446e62e4d42e80bb4 Mon Sep 17 00:00:00 2001 +From: =?UTF-8?q?Carlos=20L=C3=B3pez?= +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 + +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 +Signed-off-by: Borislav Petkov (AMD) +Tested-by: Michael Roth +Cc: stable@kernel.org +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman +--- + 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; + } diff --git a/queue-6.18/x86-kexec-push-kjump-return-address-even-for-non-kjump-kexec.patch b/queue-6.18/x86-kexec-push-kjump-return-address-even-for-non-kjump-kexec.patch new file mode 100644 index 0000000000..4b872e584d --- /dev/null +++ b/queue-6.18/x86-kexec-push-kjump-return-address-even-for-non-kjump-kexec.patch @@ -0,0 +1,52 @@ +From 786a45757dcdf8f2beb9d4a6db605db16c18b2b4 Mon Sep 17 00:00:00 2001 +From: David Woodhouse +Date: Tue, 28 Apr 2026 21:59:52 +0100 +Subject: x86/kexec: Push kjump return address even for non-kjump kexec + +From: David Woodhouse + +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 +Signed-off-by: David Woodhouse +Signed-off-by: Borislav Petkov (AMD) +Acked-by: Dave Hansen +Tested-by: Rohan Kakulawaram +Cc: +Link: https://patch.msgid.link/32d627134143ffd957891cb697138e839c623211.camel@infradead.org +Signed-off-by: Greg Kroah-Hartman +--- + 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 + diff --git a/queue-6.18/xfs-fix-memory-leak-on-error-in-xfs_alloc_zone_info.patch b/queue-6.18/xfs-fix-memory-leak-on-error-in-xfs_alloc_zone_info.patch new file mode 100644 index 0000000000..a26cbba383 --- /dev/null +++ b/queue-6.18/xfs-fix-memory-leak-on-error-in-xfs_alloc_zone_info.patch @@ -0,0 +1,39 @@ +From 592975da8c3ca87b043077e6eafa37665eae7936 Mon Sep 17 00:00:00 2001 +From: Wilfred Mallawa +Date: Wed, 15 Apr 2026 09:45:14 +1000 +Subject: xfs: fix memory leak on error in xfs_alloc_zone_info() + +From: Wilfred Mallawa + +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 +Reviewed-by: Carlos Maiolino +Signed-off-by: Wilfred Mallawa +Reviewed-by: Hans Holmberg +Reviewed-by: Christoph Hellwig +Reviewed-by: Darrick J. Wong +Signed-off-by: Carlos Maiolino +Signed-off-by: Greg Kroah-Hartman +--- + 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;