From: Greg Kroah-Hartman Date: Wed, 20 May 2026 14:52:01 +0000 (+0200) Subject: 6.12-stable patches X-Git-Tag: v6.6.141~51 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=3159d8335ea9a3b1c0e23d19f5213d744f156ba2;p=thirdparty%2Fkernel%2Fstable-queue.git 6.12-stable patches added patches: alsa-usb-audio-bound-midi-2.0-endpoint-descriptor-scans.patch alsa-usb-audio-bound-midi-endpoint-descriptor-scans.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-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-vt-d-disable-dmar-for-intel-q35-igfx.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 powerpc-warp-fix-error-handling-in-pika_dtm_thread.patch smb-client-fix-possible-infinite-loop-and-oob-read-in-symlink_data.patch --- diff --git a/queue-6.12/alsa-usb-audio-bound-midi-2.0-endpoint-descriptor-scans.patch b/queue-6.12/alsa-usb-audio-bound-midi-2.0-endpoint-descriptor-scans.patch new file mode 100644 index 0000000000..32f0250c35 --- /dev/null +++ b/queue-6.12/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 +@@ -504,15 +504,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.12/alsa-usb-audio-bound-midi-endpoint-descriptor-scans.patch b/queue-6.12/alsa-usb-audio-bound-midi-endpoint-descriptor-scans.patch new file mode 100644 index 0000000000..8b1cf4e42f --- /dev/null +++ b/queue-6.12/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 +@@ -1959,15 +1959,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.12/ceph-fix-a-buffer-leak-in-__ceph_setxattr.patch b/queue-6.12/ceph-fix-a-buffer-leak-in-__ceph_setxattr.patch new file mode 100644 index 0000000000..5b0c0e1c63 --- /dev/null +++ b/queue-6.12/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.12/ceph-fix-bug_on-in-__ceph_build_xattrs_blob-due-to-stale-blob-size.patch b/queue-6.12/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.12/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.12/drm-i915-dp-fix-vsc-dynamic-range-signaling-for-rgb-formats.patch b/queue-6.12/drm-i915-dp-fix-vsc-dynamic-range-signaling-for-rgb-formats.patch new file mode 100644 index 0000000000..94ec82c0e8 --- /dev/null +++ b/queue-6.12/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 +@@ -2726,8 +2726,13 @@ static void intel_dp_compute_vsc_colorim + drm_WARN_ON(&dev_priv->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.12/drm-i915-skip-__i915_request_skip-for-already-signaled-requests.patch b/queue-6.12/drm-i915-skip-__i915_request_skip-for-already-signaled-requests.patch new file mode 100644 index 0000000000..eb71538868 --- /dev/null +++ b/queue-6.12/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 +@@ -135,7 +135,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.12/drm-loongson-use-managed-kms-polling.patch b/queue-6.12/drm-loongson-use-managed-kms-polling.patch new file mode 100644 index 0000000000..e97d41adfd --- /dev/null +++ b/queue-6.12/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.12/drm-panfrost-fix-wait_bo-ioctl-leaking-positive-return-from-dma_resv_wait_timeout.patch b/queue-6.12/drm-panfrost-fix-wait_bo-ioctl-leaking-positive-return-from-dma_resv_wait_timeout.patch new file mode 100644 index 0000000000..bb5549150a --- /dev/null +++ b/queue-6.12/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 +@@ -325,6 +325,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.12/drm-xe-dma-buf-handle-empty-bo-and-uaf-races.patch b/queue-6.12/drm-xe-dma-buf-handle-empty-bo-and-uaf-races.patch new file mode 100644 index 0000000000..a1a4a69549 --- /dev/null +++ b/queue-6.12/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 +@@ -278,15 +278,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) +@@ -299,21 +309,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.12/io-wq-check-that-the-predecessor-is-hashed-in-io_wq_remove_pending.patch b/queue-6.12/io-wq-check-that-the-predecessor-is-hashed-in-io_wq_remove_pending.patch new file mode 100644 index 0000000000..6389e2b2fd --- /dev/null +++ b/queue-6.12/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 +@@ -1044,7 +1044,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.12/iommu-vt-d-disable-dmar-for-intel-q35-igfx.patch b/queue-6.12/iommu-vt-d-disable-dmar-for-intel-q35-igfx.patch new file mode 100644 index 0000000000..b53d214e5d --- /dev/null +++ b/queue-6.12/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 +@@ -4684,6 +4684,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.12/irqchip-riscv-imsic-clear-interrupt-move-state-during-cpu-offlining.patch b/queue-6.12/irqchip-riscv-imsic-clear-interrupt-move-state-during-cpu-offlining.patch new file mode 100644 index 0000000000..10cdf35be7 --- /dev/null +++ b/queue-6.12/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 +@@ -139,6 +139,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.12/libceph-fix-potential-null-ptr-deref-in-decode_choose_args.patch b/queue-6.12/libceph-fix-potential-null-ptr-deref-in-decode_choose_args.patch new file mode 100644 index 0000000000..7a64c772f7 --- /dev/null +++ b/queue-6.12/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.12/libceph-fix-potential-out-of-bounds-access-in-crush_decode.patch b/queue-6.12/libceph-fix-potential-out-of-bounds-access-in-crush_decode.patch new file mode 100644 index 0000000000..d332361d16 --- /dev/null +++ b/queue-6.12/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.12/libceph-fix-potential-out-of-bounds-access-in-osdmap_decode.patch b/queue-6.12/libceph-fix-potential-out-of-bounds-access-in-osdmap_decode.patch new file mode 100644 index 0000000000..ceb90d1ac8 --- /dev/null +++ b/queue-6.12/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.12/libceph-handle-rbtree-insertion-error-in-decode_choose_args.patch b/queue-6.12/libceph-handle-rbtree-insertion-error-in-decode_choose_args.patch new file mode 100644 index 0000000000..da149f5706 --- /dev/null +++ b/queue-6.12/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.12/netfs-fix-error-handling-in-netfs_extract_user_iter.patch b/queue-6.12/netfs-fix-error-handling-in-netfs_extract_user_iter.patch new file mode 100644 index 0000000000..bcb36f14ef --- /dev/null +++ b/queue-6.12/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.12/powerpc-warp-fix-error-handling-in-pika_dtm_thread.patch b/queue-6.12/powerpc-warp-fix-error-handling-in-pika_dtm_thread.patch new file mode 100644 index 0000000000..a46dda1334 --- /dev/null +++ b/queue-6.12/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.12/series b/queue-6.12/series index 82379aa260..6752b0bfe8 100644 --- a/queue-6.12/series +++ b/queue-6.12/series @@ -622,3 +622,22 @@ kvm-x86-fix-xen-hypercall-tracepoint-argument-assignment.patch netfilter-nf_tables-unconditionally-bump-set-nelems-.patch ata-libata-scsi-fix-requeue-of-deferred-ata-pass-thr.patch bluetooth-btmtk-accept-too-short-wmt-func_ctrl-events.patch +smb-client-fix-possible-infinite-loop-and-oob-read-in-symlink_data.patch +drm-loongson-use-managed-kms-polling.patch +drm-i915-dp-fix-vsc-dynamic-range-signaling-for-rgb-formats.patch +alsa-usb-audio-bound-midi-2.0-endpoint-descriptor-scans.patch +alsa-usb-audio-bound-midi-endpoint-descriptor-scans.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 +powerpc-warp-fix-error-handling-in-pika_dtm_thread.patch +netfs-fix-error-handling-in-netfs_extract_user_iter.patch +irqchip-riscv-imsic-clear-interrupt-move-state-during-cpu-offlining.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 +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 diff --git a/queue-6.12/smb-client-fix-possible-infinite-loop-and-oob-read-in-symlink_data.patch b/queue-6.12/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.12/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) &&