--- /dev/null
+From 918be519c7876329e1b6e2ea1c59f0b75e792dca Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?C=C3=A1ssio=20Gabriel?= <cassiogabrielcontato@gmail.com>
+Date: Thu, 7 May 2026 00:40:52 -0300
+Subject: ALSA: usb-audio: Bound MIDI 2.0 endpoint descriptor scans
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Cássio Gabriel <cassiogabrielcontato@gmail.com>
+
+commit 918be519c7876329e1b6e2ea1c59f0b75e792dca upstream.
+
+The USB MIDI 2.0 endpoint parser has the same descriptor walking
+pattern as the legacy MIDI parser. It validates bLength against
+bNumGrpTrmBlock before reading baAssoGrpTrmBlkID[], but not against the
+remaining bytes in the endpoint-extra scan.
+
+A malformed device can therefore make later baAssoGrpTrmBlkID[] reads
+consume bytes past the walked descriptor.
+
+Reject zero-length and overlong descriptors while walking endpoint
+extras.
+
+Fixes: ff49d1df79ae ("ALSA: usb-audio: USB MIDI 2.0 UMP support")
+Cc: stable@vger.kernel.org
+Signed-off-by: Cássio Gabriel <cassiogabrielcontato@gmail.com>
+Link: https://patch.msgid.link/20260507-usb-midi-endpoint-scan-bounds-v1-2-329d7348160e@gmail.com
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ sound/usb/midi2.c | 12 +++++++-----
+ 1 file changed, 7 insertions(+), 5 deletions(-)
+
+--- a/sound/usb/midi2.c
++++ b/sound/usb/midi2.c
+@@ -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;
+ }
--- /dev/null
+From d6854daa67be623860f4e1873fd3d3c275aba4ed Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?C=C3=A1ssio=20Gabriel?= <cassiogabrielcontato@gmail.com>
+Date: Thu, 7 May 2026 00:40:51 -0300
+Subject: ALSA: usb-audio: Bound MIDI endpoint descriptor scans
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Cássio Gabriel <cassiogabrielcontato@gmail.com>
+
+commit d6854daa67be623860f4e1873fd3d3c275aba4ed upstream.
+
+snd_usbmidi_get_ms_info() validates the internal MIDIStreaming endpoint
+descriptor size before using baAssocJackID[], but the descriptor walker can
+still return a class-specific endpoint descriptor whose bLength exceeds the
+remaining bytes in the endpoint-extra scan.
+
+That leaves later flexible-array reads bounded by bLength, but not by the
+remaining bytes in the endpoint-extra scan.
+
+Stop walking when bLength is zero or
+extends past the remaining endpoint-extra scan.
+
+Fixes: 5c6cd7021a05 ("ALSA: usb-audio: Fix case when USB MIDI interface has more than one extra endpoint descriptor")
+Cc: stable@vger.kernel.org
+Signed-off-by: Cássio Gabriel <cassiogabrielcontato@gmail.com>
+Link: https://patch.msgid.link/20260507-usb-midi-endpoint-scan-bounds-v1-1-329d7348160e@gmail.com
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ sound/usb/midi.c | 12 +++++++-----
+ 1 file changed, 7 insertions(+), 5 deletions(-)
+
+--- a/sound/usb/midi.c
++++ b/sound/usb/midi.c
+@@ -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;
+ }
--- /dev/null
+From 5d3cc36b4e77a27ce7b686b7c59c7072bcb3fa8e Mon Sep 17 00:00:00 2001
+From: Viacheslav Dubeyko <Slava.Dubeyko@ibm.com>
+Date: Thu, 9 Apr 2026 12:26:02 -0700
+Subject: ceph: fix a buffer leak in __ceph_setxattr()
+
+From: Viacheslav Dubeyko <Slava.Dubeyko@ibm.com>
+
+commit 5d3cc36b4e77a27ce7b686b7c59c7072bcb3fa8e upstream.
+
+The old_blob in __ceph_setxattr() can store
+ci->i_xattrs.prealloc_blob value during the retry.
+However, it is never called the ceph_buffer_put()
+for the old_blob object. This patch fixes the issue of
+the buffer leak.
+
+Cc: stable@vger.kernel.org
+Signed-off-by: Viacheslav Dubeyko <Slava.Dubeyko@ibm.com>
+Reviewed-by: Alex Markuze <amarkuze@redhat.com>
+Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/ceph/xattr.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/fs/ceph/xattr.c
++++ b/fs/ceph/xattr.c
+@@ -1296,6 +1296,7 @@ retry:
+
+ do_sync:
+ spin_unlock(&ci->i_ceph_lock);
++ ceph_buffer_put(old_blob);
+ do_sync_unlocked:
+ if (lock_snap_rwsem)
+ up_read(&mdsc->snap_rwsem);
--- /dev/null
+From 0c22d9511cbde746622f8e4c11aaa63fe76d45f9 Mon Sep 17 00:00:00 2001
+From: Viacheslav Dubeyko <Slava.Dubeyko@ibm.com>
+Date: Thu, 9 Apr 2026 12:43:40 -0700
+Subject: ceph: fix BUG_ON in __ceph_build_xattrs_blob() due to stale blob size
+
+From: Viacheslav Dubeyko <Slava.Dubeyko@ibm.com>
+
+commit 0c22d9511cbde746622f8e4c11aaa63fe76d45f9 upstream.
+
+The generic/642 test-case can reproduce the kernel crash:
+
+[40243.605254] ------------[ cut here ]------------
+[40243.605956] kernel BUG at fs/ceph/xattr.c:918!
+[40243.607142] Oops: invalid opcode: 0000 [#1] SMP PTI
+[40243.608067] CPU: 7 UID: 0 PID: 498762 Comm: kworker/7:1 Not tainted 7.0.0-rc7+ #3 PREEMPT(full)
+[40243.609700] Hardware name: QEMU Ubuntu 25.10 PC v2 (i440FX + PIIX, + 10.1 machine, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
+[40243.611820] Workqueue: ceph-msgr ceph_con_workfn
+[40243.612715] RIP: 0010:__ceph_build_xattrs_blob+0x1b8/0x1e0
+[40243.613731] Code: 0f 84 82 fe ff ff e9 cf 8e 56 ff 48 8d 65 e8 31 c0 5b 41 5c 41 5d 5d 31 d2 31 c9 31 f6 31 ff 45 31 c0 45 31 c9 c3 cc cc cc cc <0f> 0b 4c 8b 62 08 41 8b 85 24 07 00 00 49 83 c4 04 41 89 44 24 fc
+[40243.616888] RSP: 0018:ffffcc80c4d4b688 EFLAGS: 00010287
+[40243.617773] RAX: 0000000000010026 RBX: 0000000000000001 RCX: 0000000000000000
+[40243.618928] RDX: ffff8a773798dee0 RSI: 0000000000000000 RDI: 0000000000000000
+[40243.620158] RBP: ffffcc80c4d4b6a0 R08: 0000000000000000 R09: 0000000000000000
+[40243.621573] R10: 0000000000000000 R11: 0000000000000000 R12: ffff8a75f3b58000
+[40243.622907] R13: ffff8a75f3b58000 R14: 0000000000000080 R15: 000000000000bffd
+[40243.624054] FS: 0000000000000000(0000) GS:ffff8a787d1b4000(0000) knlGS:0000000000000000
+[40243.625331] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
+[40243.626269] CR2: 000072f390b623c0 CR3: 000000011c02a003 CR4: 0000000000372ef0
+[40243.627408] Call Trace:
+[40243.627839] <TASK>
+[40243.628188] __prep_cap+0x3fd/0x4a0
+[40243.628789] ? do_raw_spin_unlock+0x4e/0xe0
+[40243.629474] ceph_check_caps+0x46a/0xc80
+[40243.630094] ? __lock_acquire+0x4a2/0x2650
+[40243.630773] ? find_held_lock+0x31/0x90
+[40243.631347] ? handle_cap_grant+0x79f/0x1060
+[40243.632068] ? lock_release+0xd9/0x300
+[40243.632696] ? __mutex_unlock_slowpath+0x3e/0x340
+[40243.633429] ? lock_release+0xd9/0x300
+[40243.634052] handle_cap_grant+0xcf6/0x1060
+[40243.634745] ceph_handle_caps+0x122b/0x2110
+[40243.635415] mds_dispatch+0x5bd/0x2160
+[40243.636034] ? ceph_con_process_message+0x65/0x190
+[40243.636828] ? lock_release+0xd9/0x300
+[40243.637431] ceph_con_process_message+0x7a/0x190
+[40243.638184] ? kfree+0x311/0x4f0
+[40243.638749] ? kfree+0x311/0x4f0
+[40243.639268] process_message+0x16/0x1a0
+[40243.639915] ? sg_free_table+0x39/0x90
+[40243.640572] ceph_con_v2_try_read+0xf58/0x2120
+[40243.641255] ? lock_acquire+0xc8/0x300
+[40243.641863] ceph_con_workfn+0x151/0x820
+[40243.642493] process_one_work+0x22f/0x630
+[40243.643093] ? process_one_work+0x254/0x630
+[40243.643770] worker_thread+0x1e2/0x400
+[40243.644332] ? __pfx_worker_thread+0x10/0x10
+[40243.645020] kthread+0x109/0x140
+[40243.645560] ? __pfx_kthread+0x10/0x10
+[40243.646125] ret_from_fork+0x3f8/0x480
+[40243.646752] ? __pfx_kthread+0x10/0x10
+[40243.647316] ? __pfx_kthread+0x10/0x10
+[40243.647919] ret_from_fork_asm+0x1a/0x30
+[40243.648556] </TASK>
+[40243.648902] Modules linked in: overlay hctr2 libpolyval chacha libchacha adiantum libnh libpoly1305 essiv intel_rapl_msr intel_rapl_common intel_uncore_frequency_common skx_edac_common nfit kvm_intel kvm irqbypass joydev ghash_clmulni_intel aesni_intel rapl input_leds mac_hid psmouse vga16fb serio_raw vgastate floppy i2c_piix4 pata_acpi bochs qemu_fw_cfg i2c_smbus sch_fq_codel rbd dm_crypt msr parport_pc ppdev lp parport efi_pstore
+[40243.654766] ---[ end trace 0000000000000000 ]---
+
+Commit d93231a6bc8a ("ceph: prevent a client from exceeding the MDS
+maximum xattr size") moved the required_blob_size computation to before
+the __build_xattrs() call, introducing a race.
+
+__build_xattrs() releases and reacquires i_ceph_lock during execution.
+In that window, handle_cap_grant() may update i_xattrs.blob with a
+newer MDS-provided blob and bump i_xattrs.version. When
+__build_xattrs() detects that index_version < version, it destroys and
+rebuilds the entire xattr rb-tree from the new blob, potentially
+increasing count, names_size, and vals_size.
+
+The prealloc_blob size check that follows still uses the stale
+required_blob_size computed before the rebuild, so it passes even when
+prealloc_blob is too small for the now-larger tree. After __set_xattr()
+adds one more xattr on top, __ceph_build_xattrs_blob() is called from
+the cap flush path and hits:
+
+ BUG_ON(need > ci->i_xattrs.prealloc_blob->alloc_len);
+
+Fix this by recomputing required_blob_size after __build_xattrs()
+returns, using the current tree state. Also re-validate against
+m_max_xattr_size to fall back to the sync path if the rebuilt tree now
+exceeds the MDS limit.
+
+Cc: stable@vger.kernel.org
+Fixes: d93231a6bc8a ("ceph: prevent a client from exceeding the MDS maximum xattr size")
+Signed-off-by: Viacheslav Dubeyko <Slava.Dubeyko@ibm.com>
+Reviewed-by: Alex Markuze <amarkuze@redhat.com>
+Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/ceph/xattr.c | 16 ++++++++++++++++
+ 1 file changed, 16 insertions(+)
+
+--- a/fs/ceph/xattr.c
++++ b/fs/ceph/xattr.c
+@@ -1256,6 +1256,22 @@ retry:
+ ceph_vinop(inode), name, ceph_cap_string(issued));
+ __build_xattrs(inode);
+
++ /*
++ * __build_xattrs() may have released and reacquired i_ceph_lock,
++ * during which handle_cap_grant() could have replaced i_xattrs.blob
++ * with a newer MDS-provided blob and bumped i_xattrs.version. If that
++ * caused __build_xattrs() to rebuild the rb-tree from the new blob,
++ * count/names_size/vals_size may now be larger than when
++ * required_blob_size was computed above. Recompute it here so the
++ * prealloc_blob size check below reflects the current tree state.
++ */
++ required_blob_size = __get_required_blob_size(ci, name_len, val_len);
++ if (required_blob_size > mdsc->mdsmap->m_max_xattr_size) {
++ doutc(cl, "sync (size too large): %d > %llu\n",
++ required_blob_size, mdsc->mdsmap->m_max_xattr_size);
++ goto do_sync;
++ }
++
+ if (!ci->i_xattrs.prealloc_blob ||
+ required_blob_size > ci->i_xattrs.prealloc_blob->alloc_len) {
+ struct ceph_buffer *blob;
--- /dev/null
+From 1ae15b6c7965d137eef21f2cc7d367b29cb88369 Mon Sep 17 00:00:00 2001
+From: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com>
+Date: Tue, 5 May 2026 14:39:20 +0530
+Subject: drm/i915/dp: Fix VSC dynamic range signaling for RGB formats
+
+From: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com>
+
+commit 1ae15b6c7965d137eef21f2cc7d367b29cb88369 upstream.
+
+For RGB, set dynamic_range to CTA or VESA based on
+crtc_state->limited_color_range so sinks apply correct
+quantization. YCbCr remains limited (CTA) range.
+(DP v1.4, Table 5-1)
+
+v2:
+- Added Reported-by and Tested-by tags
+
+v3:
+- Add back YCbCr comment(Suraj)
+
+Cc: stable@vger.kernel.org #v5.8+
+Reported-by: DeepChirp <DeepChirp@outlook.com>
+Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/work_items/15874
+Tested-by: DeepChirp <DeepChirp@outlook.com>
+Fixes: 9799c4c3b76e ("drm/i915/dp: Add compute routine for DP VSC SDP")
+Assisted-by: GitHub-Copilot:GPT-5.4
+Signed-off-by: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com>
+Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
+Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
+Link: https://patch.msgid.link/20260505090920.2479112-1-chaitanya.kumar.borah@intel.com
+(cherry picked from commit 38e10ddae6f8d42a2e8437fcd25a1cac51106c64)
+Signed-off-by: Tvrtko Ursulin <tursulin@ursulin.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/i915/display/intel_dp.c | 9 +++++++--
+ 1 file changed, 7 insertions(+), 2 deletions(-)
+
+--- a/drivers/gpu/drm/i915/display/intel_dp.c
++++ b/drivers/gpu/drm/i915/display/intel_dp.c
+@@ -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;
+ }
+
--- /dev/null
+From 4cfe4c0efbdcde742a47813180cc69b132d7598e Mon Sep 17 00:00:00 2001
+From: Sebastian Brzezinka <sebastian.brzezinka@intel.com>
+Date: Thu, 16 Apr 2026 13:31:18 +0200
+Subject: drm/i915: skip __i915_request_skip() for already signaled requests
+
+From: Sebastian Brzezinka <sebastian.brzezinka@intel.com>
+
+commit 4cfe4c0efbdcde742a47813180cc69b132d7598e upstream.
+
+After a GPU reset the HWSP is zeroed, so previously completed
+requests appear incomplete. If such a request is picked up during
+reset_rewind() and marked guilty, i915_request_set_error_once()
+returns early (fence already signaled), leaving fence.error without
+a fatal error code. The subsequent __i915_request_skip() then hits:
+```
+GEM_BUG_ON(!fatal_error(rq->fence.error))
+```
+
+Fixes a kernel BUG observed on Sandy Bridge (Gen6) during
+heartbeat-triggered engine resets.
+```
+kernel BUG at drivers/gpu/drm/i915/i915_request.c:556!
+RIP: __i915_request_skip+0x15e/0x1d0 [i915]
+...
+__i915_request_reset+0x212/0xa70 [i915]
+reset_rewind+0xe4/0x280 [i915]
+intel_gt_reset+0x30d/0x5b0 [i915]
+heartbeat+0x516/0x530 [i915]
+```
+
+Guard __i915_request_skip() with i915_request_signaled(), if the
+fence is already signaled, the ring content is committed and there
+is nothing left to skip.
+
+Fixes: 36e191f0644b ("drm/i915: Apply i915_request_skip() on submission")
+Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/work_items/13729
+Signed-off-by: Sebastian Brzezinka <sebastian.brzezinka@intel.com>
+Cc: stable@vger.kernel.org # v5.7+
+Reviewed-by: Krzysztof Karas <krzysztof.karas@intel.com>
+Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com>
+Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com>
+Link: https://lore.kernel.org/r/fe76921d35b6ae85aa651822726d0d9815aa5362.1776339012.git.sebastian.brzezinka@intel.com
+(cherry picked from commit 5ba54393dcd7adf75a9f39f5a933b1538349cad5)
+Signed-off-by: Tvrtko Ursulin <tursulin@ursulin.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/i915/gt/intel_reset.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/drivers/gpu/drm/i915/gt/intel_reset.c
++++ b/drivers/gpu/drm/i915/gt/intel_reset.c
+@@ -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);
--- /dev/null
+From 0a9c56dd387605d17dabeedd9fdd2c4c1d0bab7b Mon Sep 17 00:00:00 2001
+From: Myeonghun Pak <mhun512@gmail.com>
+Date: Wed, 13 May 2026 15:57:00 +0900
+Subject: drm/loongson: Use managed KMS polling
+
+From: Myeonghun Pak <mhun512@gmail.com>
+
+commit 0a9c56dd387605d17dabeedd9fdd2c4c1d0bab7b upstream.
+
+lsdc_pci_probe() initializes KMS polling before setting up vblank support,
+requesting the IRQ and registering the DRM device. If any of those later
+steps fails, probe returns without finalizing polling. The driver also
+never finalizes polling on regular removal.
+
+Use drmm_kms_helper_poll_init() so polling is tied to the DRM device
+lifetime and automatically finalized on probe failure and device removal.
+
+This issue was identified during our ongoing static-analysis research while
+reviewing kernel code.
+
+Fixes: f39db26c5428 ("drm: Add kms driver for loongson display controller")
+Cc: stable@vger.kernel.org
+Co-developed-by: Ijae Kim <ae878000@gmail.com>
+Signed-off-by: Ijae Kim <ae878000@gmail.com>
+Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
+Acked-by: Jianmin Lv <lvjianmin@loongson.cn>
+Reviewed-by: Huacai Chen <chenhuacai@loongson.cn>
+Signed-off-by: Myeonghun Pak <mhun512@gmail.com>
+Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
+Link: https://patch.msgid.link/20260513065706.23803-1-mhun512@gmail.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/loongson/lsdc_drv.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/gpu/drm/loongson/lsdc_drv.c
++++ b/drivers/gpu/drm/loongson/lsdc_drv.c
+@@ -291,7 +291,7 @@ static int lsdc_pci_probe(struct pci_dev
+
+ vga_client_register(pdev, lsdc_vga_set_decode);
+
+- drm_kms_helper_poll_init(ddev);
++ drmm_kms_helper_poll_init(ddev);
+
+ if (loongson_vblank) {
+ ret = drm_vblank_init(ddev, descp->num_of_crtc);
--- /dev/null
+From 459d75523b71c0ec254d153d8850d0b7008af396 Mon Sep 17 00:00:00 2001
+From: Gyeyoung Baek <gye976@gmail.com>
+Date: Sun, 19 Apr 2026 16:17:16 +0900
+Subject: drm/panfrost: Fix wait_bo ioctl leaking positive return from dma_resv_wait_timeout()
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Gyeyoung Baek <gye976@gmail.com>
+
+commit 459d75523b71c0ec254d153d8850d0b7008af396 upstream.
+
+dma_resv_wait_timeout() returns a positive 'remaining jiffies' value
+on success, 0 on timeout, and -errno on failure.
+
+panfrost_ioctl_wait_bo() returns this 'long' result from an int-typed
+ioctl handler, so positive values reach userspace as bogus errors.
+Explicitly set ret to 0 on the success path.
+
+Fixes: f3ba91228e8e ("drm/panfrost: Add initial panfrost driver")
+Cc: stable@vger.kernel.org
+Signed-off-by: Gyeyoung Baek <gye976@gmail.com>
+Reviewed-by: Adrián Larumbe <adrian.larumbe@collabora.com>
+Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
+Reviewed-by: Steven Price <steven.price@arm.com>
+Link: https://patch.msgid.link/fe33f82fded7be1c18e2e0eb2db451d5a738cf39.1776581974.git.gye976@gmail.com
+Signed-off-by: Steven Price <steven.price@arm.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/panfrost/panfrost_drv.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/drivers/gpu/drm/panfrost/panfrost_drv.c
++++ b/drivers/gpu/drm/panfrost/panfrost_drv.c
+@@ -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);
+
--- /dev/null
+From 981bedbbe61364fcc3a3b87ebaf648a66cd07108 Mon Sep 17 00:00:00 2001
+From: Matthew Auld <matthew.auld@intel.com>
+Date: Fri, 8 May 2026 11:26:36 +0100
+Subject: drm/xe/dma-buf: handle empty bo and UAF races
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Matthew Auld <matthew.auld@intel.com>
+
+commit 981bedbbe61364fcc3a3b87ebaf648a66cd07108 upstream.
+
+There look to be some nasty races here when triggering the
+invalidate_mappings hook:
+
+1) We do xe_bo_alloc() followed by the attach, before the actual full bo
+ init step in xe_dma_buf_init_obj(). However the bo is visible on the
+ attachments list after the attach. This is bad since exporter driver,
+ say amdgpu, can at any time call back into our invalidate_mappings hook,
+ with an empty/bogus bo, leading to potential bugs/crashes.
+
+2) Similar to 1) but here we get a UAF, when the invalidate_mappings
+ hook is triggered. For example, we get as far as xe_bo_init_locked()
+ but this fails in some way. But here the bo will be freed on error, but
+ we still have it attached from dma-buf pov, so if the
+ invalidate_mappings is now triggered then the bo we access is gone and
+ we trigger UAF and more bugs/crashes.
+
+To fix this, move the attach step until after we actually have a fully
+set up buffer object. Note that the bo is not published to userspace
+until later, so not sure what the comment "Don't publish the bo
+until we have a valid attachment", is referring to.
+
+We have at least two different customers reporting hitting a NULL ptr
+deref in evict_flags when importing something from amdgpu, followed by
+triggering the evict flow. Hit rate is also pretty low, which would
+hint at some kind of race, so something like 1) or 2) might explain
+this.
+
+v2:
+ - Shuffle the order of the ops slightly (no functional change)
+ - Improve the comment to better explain the ordering (Matt B)
+
+Assisted-by: Gemini:gemini-3 #debug
+Link: https://gitlab.freedesktop.org/drm/xe/kernel/-/work_items/7903
+Link: https://gitlab.freedesktop.org/drm/xe/kernel/-/work_items/4055
+Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs")
+Signed-off-by: Matthew Auld <matthew.auld@intel.com>
+Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
+Cc: Matthew Brost <matthew.brost@intel.com>
+Cc: <stable@vger.kernel.org> # v6.8+
+Reviewed-by: Matthew Brost <matthew.brost@intel.com>
+Acked-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
+Link: https://patch.msgid.link/20260508102635.149172-3-matthew.auld@intel.com
+(cherry picked from commit af1f2ad0c59fe4e2f924c526f66e968289d77971)
+Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/xe/xe_dma_buf.c | 31 ++++++++++++++++---------------
+ 1 file changed, 16 insertions(+), 15 deletions(-)
+
+--- a/drivers/gpu/drm/xe/xe_dma_buf.c
++++ b/drivers/gpu/drm/xe/xe_dma_buf.c
+@@ -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;
+ }
--- /dev/null
+From d6a2d7b04b5a093021a7a0e2e69e9d5237dfa8cc Mon Sep 17 00:00:00 2001
+From: Nicholas Carlini <nicholas@carlini.com>
+Date: Mon, 11 May 2026 18:02:16 +0000
+Subject: io-wq: check that the predecessor is hashed in io_wq_remove_pending()
+
+From: Nicholas Carlini <nicholas@carlini.com>
+
+commit d6a2d7b04b5a093021a7a0e2e69e9d5237dfa8cc upstream.
+
+io_wq_remove_pending() needs to fix up wq->hash_tail[] if the cancelled
+work was the tail of its hash bucket. When doing this, it checks whether
+the preceding entry in acct->work_list has the same hash value, but
+never checks that the predecessor is hashed at all. io_get_work_hash()
+is simply atomic_read(&work->flags) >> IO_WQ_HASH_SHIFT, and the hash
+bits are never set for non-hashed work, so it returns 0. Thus, when a
+hashed bucket-0 work is cancelled while a non-hashed work is its list
+predecessor, the check spuriously passes and a pointer to the non-hashed
+io_kiocb is stored in wq->hash_tail[0].
+
+Because non-hashed work is dequeued via the fast path in
+io_get_next_work(), which never touches hash_tail[], the stale pointer
+is never cleared. Therefore, after the non-hashed io_kiocb completes and
+is freed back to req_cachep, wq->hash_tail[0] is a dangling pointer. The
+io_wq is per-task (tctx->io_wq) and survives ring open/close, so the
+dangling pointer persists for the lifetime of the task; the next hashed
+bucket-0 enqueue dereferences it in io_wq_insert_work() and
+wq_list_add_after() writes through freed memory.
+
+Add the missing io_wq_is_hashed() check so a non-hashed predecessor
+never inherits a hash_tail[] slot.
+
+Cc: stable@vger.kernel.org
+Fixes: 204361a77f40 ("io-wq: fix hang after cancelling pending hashed work")
+Signed-off-by: Nicholas Carlini <nicholas@carlini.com>
+Signed-off-by: Jens Axboe <axboe@kernel.dk>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ io_uring/io-wq.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/io_uring/io-wq.c
++++ b/io_uring/io-wq.c
+@@ -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;
--- /dev/null
+From 2cda2e10dc8343ae01eae9e999a876b7e7d37861 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Naval=20Alcal=C3=A1?= <ari@naval.cat>
+Date: Sat, 9 May 2026 10:43:44 +0800
+Subject: iommu/vt-d: Disable DMAR for Intel Q35 IGFX
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Naval Alcalá <ari@naval.cat>
+
+commit 2cda2e10dc8343ae01eae9e999a876b7e7d37861 upstream.
+
+Intel Q35 integrated graphics (8086:29b2) exhibits broken DMAR
+behaviour similar to other G4x/GM45 devices for which DMAR is
+already disabled via quirks.
+
+When DMAR is enabled, the system may hard lock up during boot or
+early device initialization, requiring a reset.
+
+Add the missing PCI ID to the existing quirk list to disable
+DMAR for this device.
+
+Fixes: 1f76249cc3be ("iommu/vt-d: Declare Broadwell igfx dmar support snafu")
+Cc: stable@vger.kernel.org
+Closes: https://bugzilla.kernel.org/show_bug.cgi?id=201185
+Closes: https://bugzilla.kernel.org/show_bug.cgi?id=216064
+Signed-off-by: Naval Alcalá <ari@naval.cat>
+Link: https://lore.kernel.org/r/20260410161622.13549-1-ari@naval.cat
+Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>
+Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/iommu/intel/iommu.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/drivers/iommu/intel/iommu.c
++++ b/drivers/iommu/intel/iommu.c
+@@ -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);
--- /dev/null
+From cefafbd561402b0fe6447449364a30315b9b1570 Mon Sep 17 00:00:00 2001
+From: Yong-Xuan Wang <yongxuan.wang@sifive.com>
+Date: Fri, 8 May 2026 02:31:21 -0700
+Subject: irqchip/riscv-imsic: Clear interrupt move state during CPU offlining
+
+From: Yong-Xuan Wang <yongxuan.wang@sifive.com>
+
+commit cefafbd561402b0fe6447449364a30315b9b1570 upstream.
+
+Affinity changes of IMSIC interrupts have to be careful to not lose an
+interrupt in the process. Each vector keeps track of an affinity change in
+progress with two pointers in struct imsic_vector.
+
+imsic_vector::move_prev points to the previous CPU target data and
+imsic_vector::move_next to the designated new CPU target data.
+
+imsic_vector::move_prev on the new CPU can only be cleared after the
+previous CPU has cleared imsic_vector::move_next, which ususally happens in
+__imsic_remote_sync().
+
+In case of CPU hot-unplug __imsic_remote_sync() is not invoked because the
+CPU is already marked offline. That means imsic_vector::move_prev becomes
+stale until the CPU is onlined again.
+
+The stale pointer prevents further affinity changes for the affected
+interrupts.
+
+Solve this by clearing the imsic_vector::move_prev pointers in the CPU
+hotplug offline path.
+
+[ tglx: Replace word salad in change log ]
+
+Fixes: 0f67911e821c ("irqchip/riscv-imsic: Separate next and previous pointers in IMSIC vector")
+Signed-off-by: Yong-Xuan Wang <yongxuan.wang@sifive.com>
+Signed-off-by: Thomas Gleixner <tglx@kernel.org>
+Cc: stable@vger.kernel.org
+Link: https://patch.msgid.link/20260508-imsic-v2-1-e9f08dd46cf5@sifive.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/irqchip/irq-riscv-imsic-early.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/drivers/irqchip/irq-riscv-imsic-early.c
++++ b/drivers/irqchip/irq-riscv-imsic-early.c
+@@ -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();
+
--- /dev/null
+From 28b0a2ab8c82d0bbdeb8013029c67c978ce6e4bf Mon Sep 17 00:00:00 2001
+From: Raphael Zimmer <raphael.zimmer@tu-ilmenau.de>
+Date: Tue, 12 May 2026 18:16:40 +0200
+Subject: libceph: Fix potential null-ptr-deref in decode_choose_args()
+
+From: Raphael Zimmer <raphael.zimmer@tu-ilmenau.de>
+
+commit 28b0a2ab8c82d0bbdeb8013029c67c978ce6e4bf upstream.
+
+A message of type CEPH_MSG_OSD_MAP contains an OSD map that itself
+contains a CRUSH map. When decoding this CRUSH map in crush_decode(), an
+array of max_buckets CRUSH buckets is decoded, where some indices may
+not refer to actual buckets and are therefore set to NULL. The received
+CRUSH map may optionally contain choose_args that get decoded in
+decode_choose_args(). When decoding a crush_choose_arg_map, a series of
+choose_args for different buckets is decoded, with the bucket_index
+being read from the incoming message. It is only checked that the bucket
+index does not exceed max_buckets, but not that it doesn't point to an
+index with a NULL bucket. If a (potentially corrupted) message contains
+a crush_choose_arg_map including such a bucket_index, a null pointer
+dereference may occur in the subsequent processing when attempting to
+access the bucket with the given index.
+
+This patch fixes the issue by extending the affected check. Now, it is
+only attempted to access the bucket if it is not NULL.
+
+Cc: stable@vger.kernel.org
+Signed-off-by: Raphael Zimmer <raphael.zimmer@tu-ilmenau.de>
+Reviewed-by: Ilya Dryomov <idryomov@gmail.com>
+Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/ceph/osdmap.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/net/ceph/osdmap.c
++++ b/net/ceph/osdmap.c
+@@ -390,7 +390,8 @@ static int decode_choose_args(void **p,
+ goto fail;
+
+ if (arg->ids_size &&
+- arg->ids_size != c->buckets[bucket_index]->size)
++ (!c->buckets[bucket_index] ||
++ arg->ids_size != c->buckets[bucket_index]->size))
+ goto e_inval;
+ }
+
--- /dev/null
+From 4c79fc2d598694bda845b46229c9d48b65042970 Mon Sep 17 00:00:00 2001
+From: Raphael Zimmer <raphael.zimmer@tu-ilmenau.de>
+Date: Wed, 22 Apr 2026 10:47:13 +0200
+Subject: libceph: Fix potential out-of-bounds access in crush_decode()
+
+From: Raphael Zimmer <raphael.zimmer@tu-ilmenau.de>
+
+commit 4c79fc2d598694bda845b46229c9d48b65042970 upstream.
+
+A message of type CEPH_MSG_OSD_MAP containing a crush map with at least
+one bucket has two fields holding the bucket algorithm. If the values
+in these two fields differ, an out-of-bounds access can occur. This is
+the case because the first algorithm field (alg) is used to allocate
+the correct amount of memory for a bucket of this type, while the second
+algorithm field inside the bucket (b->alg) is used in the subsequent
+processing.
+
+This patch fixes the issue by adding a check that compares alg and
+b->alg and aborts the processing in case they differ. Furthermore,
+b->alg is set to 0 in this case, because the destruction of the crush
+map also uses this field to determine the bucket type, which can again
+result in an out-of-bounds access when trying to free the memory pointed
+to by the fields of the bucket. To correctly free the memory allocated
+for the bucket in such a case, the corresponding call to kfree is moved
+from the algorithm-specific crush_destroy_bucket functions to the
+generic crush_destroy_bucket().
+
+Cc: stable@vger.kernel.org
+Signed-off-by: Raphael Zimmer <raphael.zimmer@tu-ilmenau.de>
+Reviewed-by: Ilya Dryomov <idryomov@gmail.com>
+Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/ceph/crush/crush.c | 6 +-----
+ net/ceph/osdmap.c | 4 ++++
+ 2 files changed, 5 insertions(+), 5 deletions(-)
+
+--- a/net/ceph/crush/crush.c
++++ b/net/ceph/crush/crush.c
+@@ -47,7 +47,6 @@ int crush_get_bucket_item_weight(const s
+ void crush_destroy_bucket_uniform(struct crush_bucket_uniform *b)
+ {
+ kfree(b->h.items);
+- kfree(b);
+ }
+
+ void crush_destroy_bucket_list(struct crush_bucket_list *b)
+@@ -55,14 +54,12 @@ void crush_destroy_bucket_list(struct cr
+ kfree(b->item_weights);
+ kfree(b->sum_weights);
+ kfree(b->h.items);
+- kfree(b);
+ }
+
+ void crush_destroy_bucket_tree(struct crush_bucket_tree *b)
+ {
+ kfree(b->h.items);
+ kfree(b->node_weights);
+- kfree(b);
+ }
+
+ void crush_destroy_bucket_straw(struct crush_bucket_straw *b)
+@@ -70,14 +67,12 @@ void crush_destroy_bucket_straw(struct c
+ kfree(b->straws);
+ kfree(b->item_weights);
+ kfree(b->h.items);
+- kfree(b);
+ }
+
+ void crush_destroy_bucket_straw2(struct crush_bucket_straw2 *b)
+ {
+ kfree(b->item_weights);
+ kfree(b->h.items);
+- kfree(b);
+ }
+
+ void crush_destroy_bucket(struct crush_bucket *b)
+@@ -99,6 +94,7 @@ void crush_destroy_bucket(struct crush_b
+ crush_destroy_bucket_straw2((struct crush_bucket_straw2 *)b);
+ break;
+ }
++ kfree(b);
+ }
+
+ /**
+--- a/net/ceph/osdmap.c
++++ b/net/ceph/osdmap.c
+@@ -518,6 +518,10 @@ static struct crush_map *crush_decode(vo
+ b->id = ceph_decode_32(p);
+ b->type = ceph_decode_16(p);
+ b->alg = ceph_decode_8(p);
++ if (b->alg != alg) {
++ b->alg = 0;
++ goto bad;
++ }
+ b->hash = ceph_decode_8(p);
+ b->weight = ceph_decode_32(p);
+ b->size = ceph_decode_32(p);
--- /dev/null
+From 35d0ed82d03e5ee77ea4f31f20e29562a7721649 Mon Sep 17 00:00:00 2001
+From: Raphael Zimmer <raphael.zimmer@tu-ilmenau.de>
+Date: Tue, 5 May 2026 11:08:12 +0200
+Subject: libceph: Fix potential out-of-bounds access in osdmap_decode()
+
+From: Raphael Zimmer <raphael.zimmer@tu-ilmenau.de>
+
+commit 35d0ed82d03e5ee77ea4f31f20e29562a7721649 upstream.
+
+When decoding osd_state and osd_weight from an incoming osdmap in
+osdmap_decode(), both are decoded for each osd, i.e., map->max_osd
+times. The ceph_decode_need() check only accounts for
+sizeof(*map->osd_weight) once. This can potentially result in an
+out-of-bounds memory access if the incoming message is corrupted such
+that the max_osd value exceeds the actual content of the osdmap message.
+
+This patch fixes the issue by changing the corresponding part in the
+ceph_decode_need() check to account for
+map->max_osd*sizeof(*map->osd_weight).
+
+Cc: stable@vger.kernel.org
+Fixes: dcbc919a5dc8 ("libceph: switch osdmap decoding to use ceph_decode_entity_addr")
+Signed-off-by: Raphael Zimmer <raphael.zimmer@tu-ilmenau.de>
+Reviewed-by: Ilya Dryomov <idryomov@gmail.com>
+Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/ceph/osdmap.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/net/ceph/osdmap.c
++++ b/net/ceph/osdmap.c
+@@ -1703,7 +1703,7 @@ static int osdmap_decode(void **p, void
+ ceph_decode_need(p, end, 3*sizeof(u32) +
+ map->max_osd*(struct_v >= 5 ? sizeof(u32) :
+ sizeof(u8)) +
+- sizeof(*map->osd_weight), e_inval);
++ map->max_osd*sizeof(*map->osd_weight), e_inval);
+ if (ceph_decode_32(p) != map->max_osd)
+ goto e_inval;
+
--- /dev/null
+From d289478cfc0bcf81c7914200d6abdcb78bd04ded Mon Sep 17 00:00:00 2001
+From: Raphael Zimmer <raphael.zimmer@tu-ilmenau.de>
+Date: Tue, 12 May 2026 09:29:30 +0200
+Subject: libceph: handle rbtree insertion error in decode_choose_args()
+
+From: Raphael Zimmer <raphael.zimmer@tu-ilmenau.de>
+
+commit d289478cfc0bcf81c7914200d6abdcb78bd04ded upstream.
+
+A message of type CEPH_MSG_OSD_MAP contains an OSD map that itself
+contains a CRUSH map. The received CRUSH map may optionally contain
+choose_args that get decoded in decode_choose_args(). In this function,
+num_choose_arg_maps is read from the message, and a corresponding number
+of crush_choose_arg_maps gets decoded afterwards. Each
+crush_choose_arg_map has a choose_args_index, which serves as the key
+when inserting it into the choose_args rbtree of the decoded crush_map.
+If a (potentially corrupted) message contains two crush_choose_arg_maps
+with the same index, the assertion in insert_choose_arg_map() triggers a
+kernel BUG when trying to insert the second crush_choose_arg_map.
+
+This patch fixes the issue by switching to the non-asserting rbtree
+insertion function and rejecting the message if the insertion fails.
+
+[ idryomov: changelog ]
+
+Cc: stable@vger.kernel.org
+Signed-off-by: Raphael Zimmer <raphael.zimmer@tu-ilmenau.de>
+Reviewed-by: Ilya Dryomov <idryomov@gmail.com>
+Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/ceph/osdmap.c | 5 ++++-
+ 1 file changed, 4 insertions(+), 1 deletion(-)
+
+--- a/net/ceph/osdmap.c
++++ b/net/ceph/osdmap.c
+@@ -395,7 +395,10 @@ static int decode_choose_args(void **p,
+ goto e_inval;
+ }
+
+- insert_choose_arg_map(&c->choose_args, arg_map);
++ if (!__insert_choose_arg_map(&c->choose_args, arg_map)) {
++ ret = -EEXIST;
++ goto fail;
++ }
+ }
+
+ return 0;
--- /dev/null
+From 0aad5704c6b4d14007d4eab15883e8524e4310f4 Mon Sep 17 00:00:00 2001
+From: Paulo Alcantara <pc@manguebit.org>
+Date: Tue, 12 May 2026 13:33:46 +0100
+Subject: netfs: fix error handling in netfs_extract_user_iter()
+
+From: Paulo Alcantara <pc@manguebit.org>
+
+commit 0aad5704c6b4d14007d4eab15883e8524e4310f4 upstream.
+
+In netfs_extract_user_iter(), if iov_iter_extract_pages() failed to
+extract user pages, bail out on -ENOMEM, otherwise return the error
+code only if @npages == 0, allowing short DIO reads and writes to be
+issued.
+
+This fixes mmapstress02 from LTP tests against CIFS.
+
+Fixes: 85dd2c8ff368 ("netfs: Add a function to extract a UBUF or IOVEC into a BVEC iterator")
+Reported-by: Xiaoli Feng <xifeng@redhat.com>
+Signed-off-by: Paulo Alcantara (Red Hat) <pc@manguebit.org>
+Signed-off-by: David Howells <dhowells@redhat.com>
+Link: https://patch.msgid.link/20260512123404.719402-10-dhowells@redhat.com
+Cc: netfs@lists.linux.dev
+Cc: stable@vger.kernel.org
+Cc: linux-cifs@vger.kernel.org
+Cc: linux-fsdevel@vger.kernel.org
+Signed-off-by: Christian Brauner <brauner@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/netfs/iterator.c | 13 ++++++++++---
+ 1 file changed, 10 insertions(+), 3 deletions(-)
+
+--- a/fs/netfs/iterator.c
++++ b/fs/netfs/iterator.c
+@@ -22,7 +22,7 @@
+ *
+ * Extract the page fragments from the given amount of the source iterator and
+ * build up a second iterator that refers to all of those bits. This allows
+- * the original iterator to disposed of.
++ * the original iterator to be disposed of.
+ *
+ * @extraction_flags can have ITER_ALLOW_P2PDMA set to request peer-to-peer DMA be
+ * allowed on the pages extracted.
+@@ -67,8 +67,8 @@ ssize_t netfs_extract_user_iter(struct i
+ ret = iov_iter_extract_pages(orig, &pages, count,
+ max_pages - npages, extraction_flags,
+ &offset);
+- if (ret < 0) {
+- pr_err("Couldn't get user pages (rc=%zd)\n", ret);
++ if (unlikely(ret <= 0)) {
++ ret = ret ?: -EIO;
+ break;
+ }
+
+@@ -97,6 +97,13 @@ ssize_t netfs_extract_user_iter(struct i
+ npages += cur_npages;
+ }
+
++ if (ret < 0 && (ret == -ENOMEM || npages == 0)) {
++ for (i = 0; i < npages; i++)
++ unpin_user_page(bv[i].bv_page);
++ kvfree(bv);
++ return ret;
++ }
++
+ iov_iter_bvec(new, orig->data_source, bv, npages, orig_len - count);
+ return npages;
+ }
--- /dev/null
+From 108d7f951271cbd36ca36efc5e5d106966f5180c Mon Sep 17 00:00:00 2001
+From: Ma Ke <make24@iscas.ac.cn>
+Date: Sun, 16 Nov 2025 10:44:11 +0800
+Subject: powerpc/warp: Fix error handling in pika_dtm_thread
+
+From: Ma Ke <make24@iscas.ac.cn>
+
+commit 108d7f951271cbd36ca36efc5e5d106966f5180c upstream.
+
+pika_dtm_thread() acquires client through of_find_i2c_device_by_node()
+but fails to release it in error handling path. This could result in a
+reference count leak, preventing proper cleanup and potentially
+leading to resource exhaustion. Add put_device() to release the
+reference in the error handling path.
+
+Found by code review.
+
+Cc: stable@vger.kernel.org
+Fixes: 3984114f0562 ("powerpc/warp: Platform fix for i2c change")
+Signed-off-by: Ma Ke <make24@iscas.ac.cn>
+Reviewed-by: Christophe Leroy <christophe.leroy@csgroup.eu>
+Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com>
+Link: https://patch.msgid.link/20251116024411.21968-1-make24@iscas.ac.cn
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/powerpc/platforms/44x/warp.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/arch/powerpc/platforms/44x/warp.c
++++ b/arch/powerpc/platforms/44x/warp.c
+@@ -293,6 +293,8 @@ static int pika_dtm_thread(void __iomem
+ schedule_timeout(HZ);
+ }
+
++ put_device(&client->dev);
++
+ return 0;
+ }
+
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
--- /dev/null
+From 7d9a7f1f96cd617ee9e75bb22217c709038e26b8 Mon Sep 17 00:00:00 2001
+From: Ye Bin <yebin10@huawei.com>
+Date: Thu, 14 May 2026 21:14:18 +0800
+Subject: smb/client: fix possible infinite loop and oob read in symlink_data()
+
+From: Ye Bin <yebin10@huawei.com>
+
+commit 7d9a7f1f96cd617ee9e75bb22217c709038e26b8 upstream.
+
+On 32-bit architectures, the infinite loop is as follows:
+
+ len = p->ErrorDataLength == 0xfffffff8
+ u8 *next = p->ErrorContextData + len
+ next == p
+
+On 32-bit architectures, the out-of-bounds read is as follows:
+
+ len = p->ErrorDataLength == 0xfffffff0
+ u8 *next = p->ErrorContextData + len
+ next == (u8 *)p - 8
+
+Reported-by: ChenXiaoSong <chenxiaosong@kylinos.cn>
+Fixes: 76894f3e2f71 ("cifs: improve symlink handling for smb2+")
+Cc: stable@vger.kernel.org
+Signed-off-by: Ye Bin <yebin10@huawei.com>
+Reviewed-by: ChenXiaoSong <chenxiaosong@kylinos.cn>
+Signed-off-by: Steve French <stfrench@microsoft.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/smb/client/smb2file.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/fs/smb/client/smb2file.c
++++ b/fs/smb/client/smb2file.c
+@@ -49,6 +49,9 @@ static struct smb2_symlink_err_rsp *syml
+ __func__, le32_to_cpu(p->ErrorId));
+
+ len = ALIGN(le32_to_cpu(p->ErrorDataLength), 8);
++ if (len > end - ((u8 *)p + sizeof(*p)))
++ return ERR_PTR(-EINVAL);
++
+ p = (struct smb2_error_context_rsp *)(p->ErrorContextData + len);
+ }
+ } else if (le32_to_cpu(err->ByteCount) >= sizeof(*sym) &&
projects / thirdparty / kernel / stable-queue.git / commitdiff
