Vulnerabilidades

*** Pendiente de traducción *** 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 ]---

*** Pendiente de traducción *** 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)

*** Pendiente de traducción *** 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)

*** Pendiente de traducción *** 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)

*** Pendiente de traducción *** 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)

*** Pendiente de traducción *** 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)

*** Pendiente de traducción *** 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)

*** Pendiente de traducción *** 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().

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdkfd: fix 32-bit overflow in CWSR total size calculation<br /> <br /> total_cwsr_size was computed in 32-bit before being used as a BO/SVM<br /> allocation size.<br /> With large ctx_save_restore_area_size and debug_memory_size<br /> multiplied by the XCC count, the product can wrap,<br /> yielding an undersized CWSR save area that firmware later overruns.<br /> <br /> Promote total_cwsr_size to u64 and use check_add_overflow()/<br /> check_mul_overflow() in both kfd_queue_acquire_buffers() and<br /> kfd_queue_release_buffers().<br /> <br /> (cherry picked from commit 319f7e13423ae3f486b9aea82f9ad2d6af0ee608)

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdkfd: Check bounds on CRIU restore queue type and mqd size<br /> <br /> We weren&amp;#39;t checking whether the values provided in the private<br /> data in kfd CRIU restore were within bounds.<br /> <br /> For queue type, add a KFD_QUEUE_TYPE_MAX and ensure the provided<br /> type is less than it.<br /> <br /> For mqd_size, add new function mqd_size_from_queue_type and confirm<br /> that the provided mqd_size matches expectations.<br /> <br /> (cherry picked from commit f19d8086f6644083c913d70bfdeee20e1b6f46a5)

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdkfd: Check bounds in allocate_event_notification_slot<br /> <br /> The valid event ids go from 0 to KFD_SIGNAL_EVENT_LIMIT<br /> <br /> allocate_event_notification_slot has an option to specify<br /> an event id to allocate at, used by CRIU. We weren&amp;#39;t checking<br /> the bounds on that value.<br /> <br /> Check them.<br /> <br /> v2: Lower bounds check is unecessary because of idr_alloc<br /> already rejecting negative numbers. Upper bounds check should<br /> be KFD_SIGNAL_EVENT_LIMIT since the signal mode mappings might<br /> not yet exist<br /> <br /> (cherry picked from commit 6853f1f6cbbeb3f53ebbbd7286536aeb2c5d5f50)

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/virtio: bound EDID block reads to the response buffer<br /> <br /> virtio_get_edid_block() validates the read offset only against the<br /> device-supplied resp-&gt;size field, never against the fixed-size resp-&gt;edid<br /> array. The EDID block index is driven by the device-supplied extension<br /> count, so a malicious virtio-gpu backend can advertise a large size<br /> together with a high block count and read far past the array into adjacent<br /> kernel memory, which is then surfaced in the parsed EDID (an out-of-bounds<br /> read / info leak).<br /> <br /> Also reject any read whose end exceeds the size of the edid array.<br /> Conforming EDID responses stay within the array and are unaffected.