Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/dp/mst: fix buffer overflows in sideband chunk accumulation<br /> <br /> drm_dp_sideband_append_payload() has three related bugs when processing<br /> device-provided sideband reply data:<br /> <br /> 1. Zero-length curchunk_len underflow: msg_len is a 6-bit field taken<br /> directly from the DP sideband header. If a device sends msg_len=0,<br /> curchunk_len is set to zero. The condition (curchunk_idx &gt;= curchunk_len)<br /> is immediately true, and curchunk_len-1 wraps to 255 (u8 underflow).<br /> drm_dp_msg_data_crc4() reads 255 bytes from chunk[48], then memcpy()<br /> writes 255 bytes into msg[], both far out of bounds.<br /> <br /> 2. chunk[48] overflow: curchunk_len can reach 63 (6-bit field). chunk[] is<br /> only 48 bytes. Multi-iteration payload assembly appends 16-byte blocks<br /> until curchunk_idx reaches curchunk_len, writing up to 15 bytes past<br /> the end of chunk[] into msg[].<br /> <br /> 3. msg[256] overflow: each chunk contributes (curchunk_len-1) bytes to<br /> msg[]. No check ensures curlen + (curchunk_len-1) stays within msg[256],<br /> so the memcpy can spill into adjacent struct fields.<br /> <br /> All three are reachable from any DP MST device that can forge sideband<br /> reply messages on a physical connection.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/imagination: Fix double call to drm_sched_entity_fini()<br /> <br /> Call sequence of double call:<br /> pvr_context_destroy<br />   pvr_context_kill_queues<br />     pvr_queue_kill<br />       drm_sched_entity_destroy<br />         drm_sched_entity_fini // here<br />   pvr_context_put<br />     kref_put(..., pvr_context_release)<br />       pvr_context_destroy_queues<br />         pvr_queue_destroy<br />           drm_sched_entity_fini // here<br /> <br /> Call to drm_sched_entity_destroy() from pvr_context_kill_queues() calls<br /> drm_sched_entity_flush() + drm_sched_entity_fini().<br /> drm_sched_entity_flush() ensures all pending jobs are completed and<br /> drm_sched_entity_fini() ensures no further submission is allowed as<br /> per expectation from pvr_context_kill_queues(). Double call to<br /> drm_sched_entity_fini() is misuse of the API so keep call only in<br /> pvr_context_create() failure path.<br /> <br /> Stack trace for issue with addition of refcounting for DRM entity<br /> stats in commit fd177135f0e6 ("drm/sched: Account entity GPU time"):<br /> <br /> [ 789.490527] ------------[ cut here ]------------<br /> [ 789.490559] refcount_t: underflow; use-after-free.<br /> [ 789.490657] WARNING: lib/refcount.c:28 at refcount_warn_saturate+0xf4/0x144, CPU#0: kworker/u16:1/440<br /> [ 789.490695] Modules linked in: powervr drm_gpuvm drm_exec gpu_sched drm_shmem_helper xhci_plat_hcd xhci_hcd dwc3 usbcore usb_common snd_soc_simple_card snd_soc_simple_card_utils sa2ul sha512 sha256 dwc3_am62 sha1 authenc rti_wdt libsha512 at24 sch_fq_codel fuse dm_mod ipv6<br /> [ 789.490798] CPU: 0 UID: 0 PID: 440 Comm: kworker/u16:1 Not tainted 7.0.0-rc7-02049-g5e2c0700091b #22 PREEMPT<br /> [ 789.490809] Hardware name: Texas Instruments AM625 SK (DT)<br /> [ 789.490815] Workqueue: powervr-sched pvr_queue_fence_release_work [powervr]<br /> [ 789.490868] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> [ 789.490876] pc : refcount_warn_saturate+0xf4/0x144<br /> [ 789.490884] lr : refcount_warn_saturate+0xf4/0x144<br /> [ 789.490892] sp : ffff8000822cbcc0<br /> [ 789.490895] x29: ffff8000822cbcc0 x28: 0000000000000000 x27: 0000000000000000<br /> [ 789.490909] x26: 0000000000000000 x25: ffff800081b1e338 x24: ffff000004541405<br /> [ 789.490922] x23: ffff000004bea950 x22: ffff00000042e400 x21: ffff000007123e30<br /> [ 789.490935] x20: ffff000007123000 x19: ffff000007a80d50 x18: fffffffffffe7768<br /> [ 789.490948] x17: 74736574202c6e6f x16: 697461746e656d65 x15: ffff800081b269f0<br /> [ 789.490962] x14: 0000000000000030 x13: ffff800081b26a70 x12: 0000000000000211<br /> [ 789.490975] x11: 00000000000000c0 x10: 0000000000000b50 x9 : ffff8000822cbb30<br /> [ 789.490988] x8 : ffff0000014e7bb0 x7 : ffff00007725e780 x6 : 0000000372a05f49<br /> [ 789.491001] x5 : 0000000000000000 x4 : 0000000000000001 x3 : 0000000000000010<br /> [ 789.491013] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0000014e7000<br /> [ 789.491027] Call trace:<br /> [ 789.491032] refcount_warn_saturate+0xf4/0x144 (P)<br /> [ 789.491043] drm_sched_entity_fini+0x164/0x18c [gpu_sched]<br /> [ 789.491081] pvr_queue_destroy+0x64/0x134 [powervr]<br /> [ 789.491110] pvr_context_destroy_queues+0x34/0x64 [powervr]<br /> [ 789.491138] pvr_context_release+0x70/0xac [powervr]<br /> [ 789.491166] pvr_context_put.part.0+0x5c/0x7c [powervr]<br /> [ 789.491193] pvr_context_put+0x14/0x24 [powervr]<br /> [ 789.491221] pvr_queue_fence_release_work+0x20/0x38 [powervr]<br /> [ 789.491249] process_one_work+0x160/0x4c4<br /> [ 789.491264] worker_thread+0x188/0x310<br /> [ 789.491276] kthread+0x130/0x13c<br /> [ 789.491287] ret_from_fork+0x10/0x20<br /> [ 789.491300] ---[ end trace 0000000000000000 ]---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/xe/pt: Reset current_op in xe_pt_update_ops_init()<br /> <br /> xe_pt_update_ops_init() fails to reset current_op to 0. On the<br /> vm_bind path, ops_execute() calls xe_pt_update_ops_prepare() inside<br /> the xe_validation_guard() / drm_exec_until_all_locked() loop. When<br /> that loop retries due to lock contention or OOM eviction<br /> (drm_exec_retry_on_contention() / xe_validation_retry_on_oom()),<br /> xe_pt_update_ops_prepare() runs again on the same vops, and each<br /> call to bind_op_prepare() increments current_op without resetting it.<br /> <br /> After N retries current_op exceeds the array size allocated by<br /> xe_vma_ops_alloc(), causing an out-of-bounds write into<br /> SLUB-poisoned memory and a subsequent UAF crash in<br /> xe_migrate_update_pgtables_cpu() when reading the corrupted pt_op-&gt;bind.<br /> <br /> Also reset needs_svm_lock and needs_invalidation which are derived in<br /> the same prepare pass and would otherwise cause wrong migrate ops<br /> selection and redundant TLB invalidation on retry.<br /> <br /> Fix this by resetting current_op, needs_svm_lock and needs_invalidation<br /> in xe_pt_update_ops_init().<br /> <br /> v2 (Matt):<br /> - Add details in commit message.<br /> - Add Fixes tag and Cc to stable@vger.kernel.org<br /> <br /> (cherry picked from commit 046045543e530605c441063535e7dca0075369a6)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/xe/vm: Fix BO prefetch with CONSULT_MEM_ADVISE_PREF_LOC<br /> <br /> When prefetch region is DRM_XE_CONSULT_MEM_ADVISE_PREF_LOC for a BO VMA,<br /> the code used it as an index into region_to_mem_type[], causing an<br /> out-of-bounds access since the value is -1.<br /> <br /> Resolve the preferred location for BO VMAs directly: local VRAM on dGFX<br /> (using the BO&amp;#39;s tile placement) or system memory on iGPU.<br /> <br /> Discovered using AI-assisted static analysis confirmed by Intel Product<br /> Security.<br /> <br /> v2:<br /> -Fix null dereference<br /> <br /> (cherry picked from commit d9a4906ac03be9f6ed3f3b45c56c866b867fd75b)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/xe: Hold a dma-buf reference for imported BOs<br /> <br /> An imported dma-buf BO is created as a ttm_bo_type_sg BO whose<br /> reservation object is the exporter&amp;#39;s dma_buf-&gt;resv. The importer,<br /> however, only takes a dma-buf reference after a successful<br /> dma_buf_dynamic_attach(). Until then nothing keeps the exporter alive,<br /> so if the exporter is freed while the BO still references its resv, a<br /> later access to that resv is a use-after-free:<br /> <br /> Oops: general protection fault, probably for non-canonical address<br /> 0x6b6b6b6b6b6b6b9c<br /> Workqueue: ttm ttm_bo_delayed_delete [ttm]<br /> RIP: 0010:mutex_can_spin_on_owner+0x3f/0xc0<br /> <br /> This can be reached on two paths:<br /> <br /> - dma_buf_dynamic_attach() fails, or<br /> - ttm_bo_init_reserved() fails during BO creation.<br /> <br /> In both cases the BO already has bo-&gt;base.resv pointing at the exporter<br /> resv, and sg BOs are always torn down via ttm_bo_delayed_delete(), which<br /> locks bo-&gt;base.resv asynchronously - potentially after the exporter has<br /> been freed.<br /> <br /> Take the dma-buf reference in xe_bo_init_locked(), before<br /> ttm_bo_init_reserved(), so it also covers a creation failure there, and<br /> release it in xe_ttm_bo_destroy(). The reference is held for the whole<br /> BO lifetime, keeping the shared resv alive on every path.<br /> <br /> v2:<br /> - Reworked the fix to avoid creating the imported sg BO before<br /> dma_buf_dynamic_attach() succeeds.<br /> - Attach with importer_priv == NULL and make invalidate_mappings ignore<br /> incomplete imports.<br /> <br /> v3:<br /> - Dropped the xe-side reordering approach since importer_priv must be<br /> valid when dma_buf_dynamic_attach() publishes the attachment.<br /> - Per Christian&amp;#39;s suggestion on the v1 thread, keyed the check on<br /> import_attach rather than removing the sg guard entirely.<br /> - Fixes both xe and amdgpu in a single TTM patch.<br /> <br /> v4:<br /> - Moved import_attach check to after dma_resv_copy_fences() so fences<br /> are copied before returning for successful imports (Thomas).<br /> - Removed exporter-alive claim from commit message (Thomas).<br /> <br /> v5:<br /> - Add drm/xe patch to keep imported sg BOs off the LRU before attach<br /> succeeds; the TTM fix alone is not sufficient for xe if the BO is<br /> already LRU-visible. (Thomas)<br /> v4 patch:<br /> https://patchwork.freedesktop.org/patch/736663/?series=169129&amp;rev=2<br /> - Patch 1 (drm/ttm) carries Christian&amp;#39;s Reviewed-by from v4.<br /> <br /> v6:<br /> - Reworked the fix based on Thomas&amp;#39; suggestion. Instead of the TTM resv<br /> individualization (v1-v5) plus the xe off-LRU/placement handling (v5),<br /> just hold a dma-buf reference for the imported BO lifetime so the<br /> shared resv can never be freed while the BO still references it.<br /> Single xe patch, no TTM change. (Thomas)<br /> - Take the reference in xe_bo_init_locked() before ttm_bo_init_reserved()<br /> so a TTM creation failure is covered too (Thomas).<br /> - Dropped the v5 series (drm/ttm + drm/xe off-LRU); the off-LRU approach<br /> also regressed in CI BAT via ttm_bo_pipeline_gutting() creating a ghost<br /> BO that outlived the exporter.<br /> Link to v5: https://patchwork.freedesktop.org/series/169984/<br /> <br /> v7:<br /> - Move changelog above --- so it stays in the commit message.<br /> - Reorder changelog entries oldest-to-newest. (Thomas)<br /> <br /> (cherry picked from commit 3516f3fae6be35642f8f06f8a218da6425c0306a)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/xe/rtp: Add RING_FORCE_TO_NONPRIV_DENY to OA whitelists<br /> <br /> Unconditionally whitelisting OA registers is a security violation. Set<br /> RING_FORCE_TO_NONPRIV_DENY bit in OA nonpriv slots, so that OA registers<br /> don&amp;#39;t get whitelisted by default after probe, gt reset, resume and engine<br /> reset.<br /> <br /> (cherry picked from commit 90511bdcfda97211c01f1d945d4ea616578d8fca)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/xe: Return error on non-migratable faults requiring devmem<br /> <br /> Non-migratable faults that require devmem incorrectly jump to the &amp;#39;out&amp;#39;<br /> label, which squashes the error code intended to be returned to the<br /> upper layers. Fix this by returning -EACCES instead.<br /> <br /> (cherry picked from commit c4508edb2c723de93717272488ea65b165637eac)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/sysfb: Avoid possible truncation with calculating visible size<br /> <br /> Calculating the visible size of the system framebuffer can result in<br /> truncation of the result. The calculation uses 32-bit arithmetics,<br /> which can overflow if the values for height and stride are large. Fix<br /> the issue by multiplying with mul_u32_u32().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/i915/gem: Add missing nospec on parallel submit slot<br /> <br /> Add missing Spectre mitigation for userspace controlled parallel<br /> submission slot.<br /> <br /> Discovered using AI-assisted static analysis confirmed by Intel<br /> Product Security.<br /> <br /> (cherry picked from commit 15b9353deff3cf72331c387780de3cf9c316b643)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: detect_link_and_local_sink: DP alt mode timeout path leaks prev_sink reference<br /> <br /> prev_sink is unconditionally retained via dc_sink_retain at function<br /> entry, but the DP alt mode timeout path inside SIGNAL_TYPE_DISPLAY_PORT<br /> returns false without releasing prev_sink. All other return paths in the<br /> function correctly call dc_sink_release(prev_sink), making this the only<br /> missing cleanup.<br /> <br /> (cherry picked from commit 45510cf662dcf46b5d8926d454f338809f107b9d)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/imagination: acquire vm_ctx-&gt;lock before mapping memory to GPU VM<br /> <br /> The drm gpuvm code doesn&amp;#39;t protect find operation against map operation,<br /> and the driver needs to ensure a map operation shouldn&amp;#39;t happen when a<br /> find operation is in progress.<br /> <br /> In some cases a find operation will be in progress when doing map/unmap<br /> operations, and the find operation will do a NULL pointer dereference.<br /> <br /> An example of the stack trace of such NULL dereference is shown below:<br /> <br /> ```<br /> Unable to handle kernel access to user memory without uaccess routines at<br /> virtual address 0000000000000010<br /> <br /> [] drm_gpuva_find+0x28/0x6c [drm_gpuvm]<br /> [] pvr_vm_unmap+0x34/0x68 [powervr]<br /> [] pvr_ioctl_vm_unmap+0x2e/0x50 [powervr]<br /> [] drm_ioctl_kernel+0x8e/0xdc<br /> [] drm_ioctl+0x1be/0x3e0<br /> [] __riscv_sys_ioctl+0xba/0xc4<br /> [] do_trap_ecall_u+0x23e/0x3f4<br /> [] handle_exception+0x168/0x174<br /> ```<br /> <br /> As all occurences of drm_gpuva_find*() are already guarded by<br /> vm_ctx-&gt;lock, make pvr_vm_map() to acquire this lock to prevent<br /> disturbing any find operation. This fixes the NULL deference problem in<br /> drm_gpuva_find*().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/imagination: fix error checking of pvr_vm_context_lookup()<br /> <br /> Since pvr_vm_context_lookup() returns either NULL or a pointer, then stop<br /> using IS_ERR() for checking the return value.<br /> <br /> Using IS_ERR() leads to the kernel oops reported below. It can be<br /> reproduced by passing an invalid VM context handle from userspace to the<br /> DRM_IOCTL_PVR_CREATE_CONTEXT ioctl.<br /> <br /> [ 92.733119] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000148<br /> [ 92.742042] Mem abort info:<br /> [ 92.744890] ESR = 0x0000000096000004<br /> [ 92.748686] EC = 0x25: DABT (current EL), IL = 32 bits<br /> [ 92.754020] SET = 0, FnV = 0<br /> [ 92.757154] EA = 0, S1PTW = 0<br /> [ 92.760337] FSC = 0x04: level 0 translation fault<br /> [ 92.765243] Data abort info:<br /> [ 92.768129] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000<br /> [ 92.773626] CM = 0, WnR = 0, TnD = 0, TagAccess = 0<br /> [ 92.778763] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0<br /> [ 92.784098] user pgtable: 4k pages, 48-bit VAs, pgdp=000000088ed23000<br /> [ 92.790550] [0000000000000148] pgd=0000000000000000, p4d=0000000000000000<br /> [ 92.797381] Internal error: Oops: 0000000096000004 [#1] SMP<br /> [ 92.803027] Modules linked in: powervr<br /> [ 92.852533] CPU: 0 UID: 0 PID: 409 Comm: triangle Not tainted 7.1.0-rc5-g98b46e693b91 #1 PREEMPT<br /> [ 92.861385] Hardware name: Texas Instruments AM68 SK (DT)<br /> [ 92.866766] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> [ 92.873709] pc : pvr_vm_get_fw_mem_context+0x0/0xc [powervr]<br /> [ 92.879376] lr : pvr_queue_create+0x26c/0x440 [powervr]<br /> [ 92.884595] sp : ffff8000837fbb00<br /> [ 92.887895] x29: ffff8000837fbb60 x28: 0000000000000000 x27: ffff8000837fbce8<br /> [ 92.895015] x26: ffff000807f61a40 x25: ffff000807f61a00 x24: ffff000807f64400<br /> [ 92.902135] x23: ffff00080a5ab000 x22: ffff800079b24730 x21: ffff000807f61800<br /> [ 92.909254] x20: ffff00080999e680 x19: 0000000000000000 x18: 0000000000000000<br /> [ 92.916373] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000001<br /> [ 92.923492] x14: 0000000000000000 x13: 0000000000000002 x12: ffff80008145b298<br /> [ 92.930611] x11: ffff8000844e5000 x10: ffff80008165a130 x9 : 0000000000000100<br /> [ 92.937730] x8 : 0000000000000001 x7 : ffff0008076b27e0 x6 : ffff00080ec43b7c<br /> [ 92.944850] x5 : ffff00080ec43b78 x4 : 0000000000000000 x3 : ffff00080999e680<br /> [ 92.951968] x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000<br /> [ 92.959088] Call trace:<br /> [ 92.961521] pvr_vm_get_fw_mem_context+0x0/0xc [powervr] (P)<br /> [ 92.967173] pvr_context_create+0x190/0x410 [powervr]<br /> [ 92.972218] pvr_ioctl_create_context+0x44/0x8c [powervr]<br /> [ 92.977608] drm_ioctl_kernel+0xbc/0x124 [drm]<br /> [ 92.982127] drm_ioctl+0x1f8/0x4dc [drm]<br /> [ 92.986098] __arm64_sys_ioctl+0xac/0x104<br /> [ 92.990102] invoke_syscall+0x54/0x10c<br /> [ 92.993842] el0_svc_common.constprop.0+0x40/0xe0<br /> [ 92.998532] do_el0_svc+0x1c/0x28<br /> [ 93.001835] el0_svc+0x38/0x11c<br /> [ 93.004969] el0t_64_sync_handler+0xa0/0xe4<br /> [ 93.009139] el0t_64_sync+0x198/0x19c<br /> [ 93.012792] Code: aa1703e0 d2800014 95cb0ba4 17ffffe8 (f940a400)<br /> [ 93.018869] ---[ end trace 0000000000000000 ]---