<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/drivers/gpu, branch v6.12.92</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v6.12.92</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v6.12.92'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2026-06-01T15:46:33+00:00</updated>
<entry>
<title>drm/xe/oa: Fix exec_queue leak on width check in stream open</title>
<updated>2026-06-01T15:46:33+00:00</updated>
<author>
<name>Shuicheng Lin</name>
<email>shuicheng.lin@intel.com</email>
</author>
<published>2026-05-14T20:32:10+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=ede0dda8a3937899988a3f8826664e97c7925be4'/>
<id>urn:sha1:ede0dda8a3937899988a3f8826664e97c7925be4</id>
<content type='text'>
[ Upstream commit 4d25342543c01310fc4e0cba7cb17c775e2421e2 ]

In xe_oa_stream_open_ioctl(), when param.exec_q-&gt;width &gt; 1 the
function returns -EOPNOTSUPP directly, skipping the existing
err_exec_q cleanup path. The exec_queue reference obtained by
xe_exec_queue_lookup() is leaked.

The exec queue holds a reference on the xe_file, which is only
dropped during queue teardown. The leaked lookup ref is not on
the file's exec_queue xarray, so file close cannot release it.
This keeps both the exec queue and the file private state pinned
indefinitely.

Jump to err_exec_q instead of returning directly so the reference
is released.

Fixes: f0ed39830e60 ("xe/oa: Fix query mode of operation for OAR/OAC")
Assisted-by: Claude:claude-opus-4.6
Reviewed-by: Ashutosh Dixit &lt;ashutosh.dixit@intel.com&gt;
Link: https://patch.msgid.link/20260514203210.593488-1-shuicheng.lin@intel.com
Signed-off-by: Shuicheng Lin &lt;shuicheng.lin@intel.com&gt;
(cherry picked from commit 339fa0be9e4a5d69fa47e91f4a36574224fb478f)
Signed-off-by: Rodrigo Vivi &lt;rodrigo.vivi@intel.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>drm/i915/dp: Fix readback for target_rr in Adaptive Sync SDP</title>
<updated>2026-06-01T15:46:31+00:00</updated>
<author>
<name>Ankit Nautiyal</name>
<email>ankit.k.nautiyal@intel.com</email>
</author>
<published>2026-05-11T12:32:15+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=bfe6b5d9ca35c776b9c1a7191bab24698e1e3d4d'/>
<id>urn:sha1:bfe6b5d9ca35c776b9c1a7191bab24698e1e3d4d</id>
<content type='text'>
[ Upstream commit f87abd0c6604fb6cc31cc86fc7ccc6a576924352 ]

Correct the bit-shift logic to properly readback the 10 bit target_rr from
DB3 and DB4.

v2: Align the style with readback for vtotal. (Ville)

Fixes: 12ea89291603 ("drm/i915/dp: Add Read/Write support for Adaptive Sync SDP")
Cc: Mitul Golani &lt;mitulkumar.ajitkumar.golani@intel.com&gt;
Cc: Ankit Nautiyal &lt;ankit.k.nautiyal@intel.com&gt;
Signed-off-by: Ankit Nautiyal &lt;ankit.k.nautiyal@intel.com&gt;
Reviewed-by: Ville Syrjälä &lt;ville.syrjala@linux.intel.com&gt;
Link: https://patch.msgid.link/20260511123218.1589830-2-ankit.k.nautiyal@intel.com
(cherry picked from commit f7abc4af2b19240a145a221461dfe756cc01d74a)
Signed-off-by: Tvrtko Ursulin &lt;tursulin@ursulin.net&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>drm/xe/pf: Fix CFI failure in debugfs access</title>
<updated>2026-06-01T15:46:30+00:00</updated>
<author>
<name>Mohanram Meenakshisundaram</name>
<email>mohanram.meenakshisundaram@intel.com</email>
</author>
<published>2026-05-14T17:49:18+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=c57bb1340a9af617f55d3c731c6331be4024c7c0'/>
<id>urn:sha1:c57bb1340a9af617f55d3c731c6331be4024c7c0</id>
<content type='text'>
[ Upstream commit 96bf49b526e2d03a2b7f6e861925a08f46ed0d28 ]

Reading debugfs file (/sys/kernel/debug/dri/0/gt*/pf/adverse_events)
with CFI (Control Flow Integrity) enabled, the kernel panics at
xe_gt_debugfs_simple_show+0x82/0xc0.

xe_gt_debugfs_simple_show() declare a function pointer expecting int
return type, but xe_gt_sriov_pf_monitor_print_events() is void return
type, leading to CFI failure and kernel panic.

[507620.973657] CFI failure at xe_gt_debugfs_simple_show+0x82/0xc0 [xe]
(target: xe_gt_sriov_pf_monitor_print_events+0x0/0x130 [xe]; expected
type: 0xd72c7139)

Fix xe_gt_sriov_pf_monitor_print_events() function by updating to return
an int type.

Fixes: 1c99d3d3edab ("drm/xe/pf: Expose PF monitor details via debugfs")
Signed-off-by: Mohanram Meenakshisundaram &lt;mohanram.meenakshisundaram@intel.com&gt;
Reviewed-by: Michal Wajdeczko &lt;michal.wajdeczko@intel.com&gt;
Signed-off-by: Michal Wajdeczko &lt;michal.wajdeczko@intel.com&gt;
Link: https://patch.msgid.link/20260514174918.1556357-2-mohanram.meenakshisundaram@intel.com
(cherry picked from commit ff1d386a8359746d9699ac30336e3b0684c68958)
Signed-off-by: Rodrigo Vivi &lt;rodrigo.vivi@intel.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>drm/xe/vf: Fix signature of print functions</title>
<updated>2026-06-01T15:46:30+00:00</updated>
<author>
<name>Michal Wajdeczko</name>
<email>michal.wajdeczko@intel.com</email>
</author>
<published>2026-05-14T15:57:26+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=a7760d092a5ad5f019cd45237a179531010f7b73'/>
<id>urn:sha1:a7760d092a5ad5f019cd45237a179531010f7b73</id>
<content type='text'>
[ Upstream commit 9bb2f1d7e6e58b8e434ddc2048c661bf87ccdf2a ]

We have plugged-in existing VF print functions into our GT debugfs
show helper as-is, but we missed that the helper expects functions
to return int, while they were defined as void. This can lead to
errors being reported when CFI is enabled.

Fixes: 63d8cb8fe3dd ("drm/xe/vf: Expose SR-IOV VF attributes to GT debugfs")
Signed-off-by: Michal Wajdeczko &lt;michal.wajdeczko@intel.com&gt;
Cc: Mohanram Meenakshisundaram &lt;mohanram.meenakshisundaram@intel.com&gt;
Reviewed-by: Shuicheng Lin &lt;shuicheng.lin@intel.com&gt;
Link: https://patch.msgid.link/20260514155726.7165-1-michal.wajdeczko@intel.com
(cherry picked from commit 314e31c9a8a1c421ee4f7f755b9348aefbbca090)
Signed-off-by: Rodrigo Vivi &lt;rodrigo.vivi@intel.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>drm/xe/gsc: Fix double-free of managed BO in error path</title>
<updated>2026-06-01T15:46:30+00:00</updated>
<author>
<name>Shuicheng Lin</name>
<email>shuicheng.lin@intel.com</email>
</author>
<published>2026-05-11T15:41:34+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=7cb975fcd4777e7bad688f66aa0c10c16dd8276b'/>
<id>urn:sha1:7cb975fcd4777e7bad688f66aa0c10c16dd8276b</id>
<content type='text'>
[ Upstream commit d3ded53fab90996e7d94a39049e11962dd066725 ]

The error path in xe_gsc_init_post_hwconfig() explicitly frees a BO
allocated with xe_managed_bo_create_pin_map() via
xe_bo_unpin_map_no_vm(). Since the managed BO already has a devm
cleanup action registered, this causes a double-free when devm
unwinds during probe failure.

Remove the explicit free and let devm handle it, consistent with
all other xe_managed_bo_create_pin_map() callers.

Fixes: 2e5d47fe7839 ("drm/xe/uc: Use managed bo for HuC and GSC objects")
Reviewed-by: Daniele Ceraolo Spurio &lt;daniele.ceraolospurio@intel.com&gt;
Assisted-by: Claude:claude-opus-4.6
Link: https://patch.msgid.link/20260511154134.223696-1-shuicheng.lin@intel.com
Signed-off-by: Shuicheng Lin &lt;shuicheng.lin@intel.com&gt;
(cherry picked from commit 71d61e3e299a17139e47f980a4d6f425b2c59bf7)
Signed-off-by: Rodrigo Vivi &lt;rodrigo.vivi@intel.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>drm/msm/snapshot: fix dumping of the unaligned regions</title>
<updated>2026-06-01T15:46:30+00:00</updated>
<author>
<name>Dmitry Baryshkov</name>
<email>dmitry.baryshkov@oss.qualcomm.com</email>
</author>
<published>2026-05-16T11:53:45+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=1ef79be774706dddcfcace0331fa7ff32a73c73e'/>
<id>urn:sha1:1ef79be774706dddcfcace0331fa7ff32a73c73e</id>
<content type='text'>
[ Upstream commit 76824d2467feb1828b745d6add2541918d7be3da ]

The snapshotting code internally aligns data segment to 16 bytes. This
works fine for DPU code (where most of the regions are aligned), but
fails for snapshotting of the DSI data (because DSI data region is
shifted by 4 bytes). Fix the code by removing length alignment and by
accurately printing last registers in the region. While reworking the
code also fix the 16x memory overallocation in
msm_disp_state_dump_regs().

Fixes: 98659487b845 ("drm/msm: add support to take dpu snapshot")
Reported-by: Salendarsingh Gaud &lt;sgaud@qti.qualcomm.com&gt;
Signed-off-by: Dmitry Baryshkov &lt;dmitry.baryshkov@oss.qualcomm.com&gt;
Patchwork: https://patchwork.freedesktop.org/patch/725449/
Message-ID: &lt;20260516-msm-fix-dsi-dump-2-v2-1-9e49fb2d240e@oss.qualcomm.com&gt;
Signed-off-by: Rob Clark &lt;robin.clark@oss.qualcomm.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>drm/msm: Fix iommu_map_sgtable() return value check and avoid WARN</title>
<updated>2026-06-01T15:46:29+00:00</updated>
<author>
<name>Mikko Perttunen</name>
<email>mperttunen@nvidia.com</email>
</author>
<published>2026-04-21T04:02:38+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=3457807aeb88077712f0a7cb65c3ca5120773d75'/>
<id>urn:sha1:3457807aeb88077712f0a7cb65c3ca5120773d75</id>
<content type='text'>
[ Upstream commit 55e0f0d1c1a4ee1e46da7da4d443eb3044fb3851 ]

Commit "iommu: return full error code from iommu_map_sg[_atomic]()"
changed iommu_map_sgtable() to return an ssize_t and negative values
in error cases, rather than a size_t and a zero.

Store the return value in the appropriate type and in case of error,
return it rather than WARNing.

Fixes: ad8f36e4b6b1 ("iommu: return full error code from iommu_map_sg[_atomic]()")
Signed-off-by: Mikko Perttunen &lt;mperttunen@nvidia.com&gt;
Patchwork: https://patchwork.freedesktop.org/patch/719685/
Message-ID: &lt;20260421-iommu_map_sgtable-return-v1-3-fb484c07d2a1@nvidia.com&gt;
Signed-off-by: Rob Clark &lt;robin.clark@oss.qualcomm.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>drm/msm/dsi: don't dump registers past the mapped region</title>
<updated>2026-06-01T15:46:29+00:00</updated>
<author>
<name>Dmitry Baryshkov</name>
<email>dmitry.baryshkov@oss.qualcomm.com</email>
</author>
<published>2026-04-28T17:21:38+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=9f8274749d9010a1a72f97e547b7eb9ebb82345b'/>
<id>urn:sha1:9f8274749d9010a1a72f97e547b7eb9ebb82345b</id>
<content type='text'>
[ Upstream commit 5b49a46baa853b26dbefa65c6c75dd9ff69f63d4 ]

On DSI 6G platforms the IO address space is internally adjusted by
io_offset. Later this adjusted address might be used for memory dumping.
However the size that is used for memory dumping isn't adjusted to
account for the io_offset, leading to the potential access to the
unmapped region. Lower ctrl_size by the io_offset value to prevent
access past the mapped area.

 msm_disp_snapshot_add_block+0x1d4/0x3c8 [msm] (P)
 msm_dsi_host_snapshot+0x4c/0x78 [msm]
 msm_dsi_snapshot+0x28/0x50 [msm]
 msm_disp_snapshot_capture_state+0x74/0x140 [msm]
 msm_disp_snapshot_state_sync+0x60/0x90 [msm]
 _msm_disp_snapshot_work+0x30/0x90 [msm]
 kthread_worker_fn+0xdc/0x460
 kthread+0x120/0x140

Fixes: bac2c6a62ed9 ("drm/msm: get rid of msm_iomap_size")
Signed-off-by: Dmitry Baryshkov &lt;dmitry.baryshkov@oss.qualcomm.com&gt;
Reviewed-by: Konrad Dybcio &lt;konrad.dybcio@oss.qualcomm.com&gt;
Patchwork: https://patchwork.freedesktop.org/patch/721747/
Link: https://lore.kernel.org/r/20260428-msm-fix-dsi-dump-v1-1-5d4cb5ccfac7@oss.qualcomm.com
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>drm/amd/display: Validate payload length and link_index in dc_process_dmub_aux_transfer_async</title>
<updated>2026-06-01T15:46:22+00:00</updated>
<author>
<name>Harry Wentland</name>
<email>harry.wentland@amd.com</email>
</author>
<published>2026-05-07T20:26:31+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=3265f3ed373fb8048be713aadcdf702579a0e53d'/>
<id>urn:sha1:3265f3ed373fb8048be713aadcdf702579a0e53d</id>
<content type='text'>
commit 6c92f6d9600efa3ef0d9e560a2b52776d9803c29 upstream.

[Why&amp;How]
dc_process_dmub_aux_transfer_async() copies payload-&gt;length bytes into a
16-byte stack buffer (dpaux.data[16]) guarded only by an ASSERT(), which
is a no-op in release builds. If a caller ever passes length &gt; 16 this
results in a stack buffer overflow via memcpy.

Additionally, link_index is used to dereference dc-&gt;links[] without
bounds checking against dc-&gt;link_count, risking an out-of-bounds access.

Replace the ASSERT with a hard runtime check that returns false when
payload-&gt;length exceeds the destination buffer size, and add a bounds
check for link_index before it is used.

Assisted-by: GitHub Copilot:Claude claude-4-opus
Reviewed-by: Alex Hung &lt;alex.hung@amd.com&gt;
Signed-off-by: Harry Wentland &lt;harry.wentland@amd.com&gt;
Signed-off-by: Ivan Lipski &lt;ivan.lipski@amd.com&gt;
Tested-by: Dan Wheeler &lt;daniel.wheeler@amd.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
(cherry picked from commit ba4caa9fecdf7a38f98c878ad05a8a64148b6881)
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>drm/amd/display: Validate GPIO pin LUT table size before iterating</title>
<updated>2026-06-01T15:46:22+00:00</updated>
<author>
<name>Harry Wentland</name>
<email>harry.wentland@amd.com</email>
</author>
<published>2026-05-04T20:14:11+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=67461e0c15335894cc5d3b84cda823bf8cbdc886'/>
<id>urn:sha1:67461e0c15335894cc5d3b84cda823bf8cbdc886</id>
<content type='text'>
commit 86d2b20644b11d21fe52c596e6e922b4590a3e3f upstream.

[Why&amp;How]
The GPIO pin table parsers in get_gpio_i2c_info() and
bios_parser_get_gpio_pin_info() derive an element count from the VBIOS
table_header.structuresize field, then iterate over gpio_pin[] entries.
However, GET_IMAGE() only validates that the table header itself fits
within the BIOS image. If the VBIOS reports a structuresize larger than
the actual mapped data, the loop reads past the end of the BIOS image,
causing an out-of-bounds read.

Fix this by calling bios_get_image() to validate that the full claimed
structuresize is accessible within the BIOS image before entering the
loop in both functions.

Assisted-by: GitHub Copilot:claude-opus-4-6
Reviewed-by: Alex Hung &lt;alex.hung@amd.com&gt;
Signed-off-by: Harry Wentland &lt;harry.wentland@amd.com&gt;
Signed-off-by: Ivan Lipski &lt;ivan.lipski@amd.com&gt;
Tested-by: Dan Wheeler &lt;daniel.wheeler@amd.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
(cherry picked from commit ba5e95b43b773ae1bf1f66ee6b31eb774e65afe3)
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
</feed>
