Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu/sdma6.0: replace BUG_ON() with WARN_ON()<br /> <br /> There&amp;#39;s no need to crash the kernel for these cases.<br /> <br /> (cherry picked from commit c17a508a7d652da3728f8bbc481bfffe96d65a87)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu/sdma7.0: replace BUG_ON() with WARN_ON()<br /> <br /> There&amp;#39;s no need to crash the kernel for these cases.<br /> <br /> (cherry picked from commit 9723a8bed3aa251a26bee4583bac9d8fb064dd44)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu/userq: fix indefinite fence wait during GPU reset<br /> <br /> pre_reset only force-completes fences of MAPPED queues. A queue in any<br /> other state (e.g. mid-eviction) keeps its last_fence pending; after a<br /> GPU reset that fence never signals, so the eviction/suspend worker and<br /> process teardown (amdgpu_evf_mgr_flush_suspend) wait on it forever and<br /> wedge the machine:<br /> <br /> INFO: task kworker/6:28 blocked for more than 120 seconds.<br /> Workqueue: events amdgpu_eviction_fence_suspend_worker [amdgpu]<br /> Call Trace:<br /> dma_fence_wait_timeout+0x7e/0x130<br /> amdgpu_userq_evict+0x67/0x140 [amdgpu]<br /> amdgpu_eviction_fence_suspend_worker+0xd8/0x160 [amdgpu]<br /> process_scheduled_works+0xa6/0x420<br /> <br /> Force-complete every queue&amp;#39;s fence regardless of state. The unmap and<br /> mark-hung step stays gated on MAPPED, since unmapping a queue that is<br /> not mapped is invalid.<br /> <br /> (cherry picked from commit 9102b39fa924dcc3dc75a3137bfa9633c40b88c0)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu: Release VFCT ACPI table reference<br /> <br /> amdgpu_acpi_vfct_bios() fetches the VFCT table with acpi_get_table()<br /> but never releases it. acpi_get_table() takes a reference on the<br /> table (incrementing its validation_count and mapping it on the 0-&gt;1<br /> transition); without a paired acpi_put_table() the mapping is leaked<br /> on every call, whether or not a matching VBIOS image is found.<br /> <br /> Route all exit paths after the table is acquired through a common<br /> acpi_put_table(). The VBIOS image is copied out with kmemdup() before<br /> the table is released, so it remains valid for the caller.<br /> <br /> (cherry picked from commit ca5988682b4cba4cd125a0fa99b2de1239164ae4)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/ttm: Account for NULL and handle pages in ttm_pool_backup<br /> <br /> Pages in ttm_pool_backup can be NULL or backup handles<br /> (ttm_backup_page_ptr_is_handle()), neither of which can be passed to<br /> set_pages_array_wb() or freed. Add a dedicated WB pass before the<br /> dma/purge loop that walks allocations using the same i += num_pages<br /> stride, skipping NULL and handle entries, and calls set_pages_array_wb()<br /> once per contiguous run of real pages. Apply the same NULL/handle guard<br /> to the dma/purge loop.<br /> <br /> Fixes the following oops:<br /> <br /> Oops: general protection fault, kernel NULL pointer dereference 0x0: 0000 [#1] SMP NOPTI<br /> RIP: 0010:__cpa_process_fault+0xf8/0x770<br /> RSP: 0018:ffffc90000a87718 EFLAGS: 00010287<br /> RAX: 0000000000000000 RBX: ffffc90000a87868 RCX: 0000000000000000<br /> RDX: 0000000000001000 RSI: 0005088000000000 RDI: ffffffff827c5f34<br /> RBP: 0005088000000000 R08: ffffc90000a877cb R09: ffffc90000a877d0<br /> R10: 0000000000000000 R11: 000000000000001b R12: 000ffffffffff000<br /> R13: ffffc90000a87868 R14: ffffc90000a87868 R15: ffff88815b882ae0<br /> FS: 0000000000000000(0000) GS:ffff8884ec840000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007f930b844000 CR3: 000000000262e003 CR4: 0000000008f70ef0<br /> PKRU: 55555554<br /> Call Trace:<br /> <br /> __change_page_attr_set_clr+0x989/0xe90<br /> ? __purge_vmap_area_lazy+0x6c/0x3a0<br /> ? _vm_unmap_aliases+0x250/0x2a0<br /> set_pages_array_wb+0x7f/0x120<br /> ttm_pool_backup+0x4c9/0x5b0 [ttm]<br /> ? dma_resv_wait_timeout+0x3b/0xf0<br /> ttm_tt_backup+0x32/0x60 [ttm]<br /> ttm_bo_shrink+0x66/0x110 [ttm]<br /> xe_bo_shrink_purge+0x12b/0x1b0 [xe]<br /> xe_bo_shrink+0xbb/0x270 [xe]<br /> __xe_shrinker_walk+0xf7/0x160 [xe]<br /> xe_shrinker_walk+0x9d/0xc0 [xe]<br /> xe_shrinker_scan+0x11f/0x210 [xe]<br /> do_shrink_slab+0x13b/0x270<br /> shrink_slab+0xf1/0x400<br /> shrink_node+0x352/0x8a0<br /> balance_pgdat+0x32c/0x700<br /> kswapd+0x205/0x2f0<br /> ? __pfx_autoremove_wake_function+0x10/0x10<br /> ? __pfx_kswapd+0x10/0x10<br /> kthread+0xd1/0x110<br /> ? __pfx_kthread+0x10/0x10<br /> ret_from_fork+0x1b1/0x200<br /> ? __pfx_kthread+0x10/0x10<br /> ret_from_fork_asm+0x1a/0x30<br />

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/gpusvm: publish dpagemap early to avoid device mapping leak on error<br /> <br /> drm_gpusvm_get_pages() only stored the local dpagemap into<br /> svm_pages-&gt;dpagemap on the success path. If a later page failed (e.g.<br /> -EOPNOTSUPP when ctx-&gt;allow_mixed is false) and jumped to err_unmap,<br /> svm_pages-&gt;dpagemap was still NULL, so __drm_gpusvm_unmap_pages() skipped<br /> device_unmap() and leaked the device mappings already created.<br /> <br /> Assign svm_pages-&gt;dpagemap when the first device page is mapped so the<br /> err_unmap path can device_unmap() those mappings.<br /> <br /> This issue was found by Sashiko AI review.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/i915/mst: limit DP MST ESI service loop<br /> <br /> The loop in intel_dp_check_mst_status() keeps servicing interrupts<br /> originating from the sink without bound. Add an upper bound to the new<br /> interrupts occurring during interrupt processing to not get stuck on<br /> potentially stuck sink devices. Use arbitrary 32 tries to clear incoming<br /> interrupts in one go.<br /> <br /> Discovered using AI-assisted static analysis confirmed by Intel Product<br /> Security.<br /> <br /> Note: The condition likely pre-dates the commit in the Fixes: tag, but<br /> this is about as far back as a backport has any chance of<br /> succeeding. Before that, the retry had a goto.<br /> <br /> (cherry picked from commit b4ea5272133059acb493cc36599071a9e852ec2e)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/i915/gt: Fix NULL deref on sched_engine alloc failure<br /> <br /> Avoid using intel_context_put() before intel_context_init() in<br /> execlists_create_virtual() as the kref_put() inside would lead<br /> to NULL deref on the IOCTL path when sched_engine allocation fails.<br /> <br /> Discovered using AI-assisted static analysis confirmed by<br /> Intel Product Security.<br /> <br /> (cherry picked from commit 4f2a12f2d50e9f48227656e4dcbd6423506be31d)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/i915/gem: Fix NULL deref in I915_CONTEXT_PARAM_SSEU<br /> <br /> Setting context engine slot N into I915_ENGINE_CLASS_INVALID /<br /> I915_ENGINE_CLASS_INVALID_NONE and attempting to apply<br /> I915_CONTEXT_PARAM_SSEU to the same slot N will deref NULL.<br /> Fix that.<br /> <br /> Discovered using AI-assisted static analysis confirmed by<br /> Intel Product Security.<br /> <br /> (cherry picked from commit 36eda5b5c2d40da41cc0a5403c26986237cf9e87)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/i915/gem: Do not leak siblings[] on proto context error<br /> <br /> After a successful BALANCE/PARALLEL_SUBMIT extension on context<br /> creation, error during processing of next user extension leaks<br /> the siblings[] array. Fix that.<br /> <br /> Discovered using AI-assisted static analysis confirmed by<br /> Intel Product Security.<br /> <br /> (cherry picked from commit aa65e0a4b51b3b54b53e4142aaa2d997aa1061ff)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu: fix lifetime issue of amdgpu_vm_get_task_info_pasid()<br /> <br /> The vm pointer returned from amdgpu_vm_get_vm_from_pasid() is only<br /> valid while the lock is still being held. Once xa_unlock_irqrestore is<br /> called and returned, the pointer is no longer under lock and is subject<br /> to modification. Since, the caller still dereferences vm-&gt;task_info in<br /> amdgpu_vm_get_task_info_vm() after the lock is removed, this causes a<br /> use after unlock problem.<br /> <br /> Remove the lifetime issue present in amdgpu_vm_get_task_info_pasid()<br /> through removing the amdgpu_vm_get_vm_from_pasid() function from<br /> amdgpu_vm.c and making the relevant code inline to hold the lock while<br /> it is still in use.<br /> <br /> (cherry picked from commit 9d01579f3f868b333acc901815972685989092c7)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: chips-media: wave5: Move src_buf Removal to finish_encode<br /> <br /> During encoder processing, there is a case where the IRQ response could<br /> return the buffer back to userspace via v4l2_m2m_buf_done call. In this<br /> time, userspace could queue up this same buffer before start_encode removes<br /> the index from the ready queue. This would then lead to a case where the<br /> buffer in the ready queue could be a self loop due to the<br /> WRITE_ONCE(prev-&gt;next, new) call in __list_add.<br /> <br /> When __list_del is finally called, the loop is already made so nothing<br /> points back to ready queue list head and pointers are poisoned.<br /> <br /> A buffer should not be marked as DONE before the buffer is removed from<br /> m2m ready queue. Move removal entirely to finish_encode.