Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/i915/bios: range check LFP Data Block panel_type2<br /> <br /> While the panel_type from LFP Data Block is range checked, panel_type2<br /> is not. Add a few helpers for range checking, and use them to not only<br /> check panel_type2, but also improve clarity and correctness in the panel<br /> type selection.<br /> <br /> Discovered using AI-assisted static analysis confirmed by Intel Product<br /> Security.<br /> <br /> v2:<br /> - Fix commit message typo (Michał)<br /> - Add is_panel_type_pnp() (Ville)<br /> <br /> (cherry picked from commit c9ebe5d2f25729d6cfbbb1235d640bf67f9275df)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/i915: Return NULL on error in active_instance<br /> <br /> Avoid returning &amp;node-&gt;base when node is NULL due to OOM<br /> during GFP_ATOMIC allocation.<br /> <br /> Discovered using AI-assisted static analysis confirmed by<br /> Intel Product Security.<br /> <br /> (cherry picked from commit 6029bc064f0b1bac184203a50fbaaf070fa18832)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/i915/hdcp: check streams[] bounds before overflow<br /> <br /> The data-&gt;streams[] overflow check is done after the buffer overflow has<br /> already happened. Move the overflow check before the write.<br /> <br /> Side note, emitting a warning splat with a backtrace might be overkill<br /> here, but prefer not changing the behaviour other than not doing the<br /> overrun.<br /> <br /> Discovered using AI-assisted static analysis confirmed by Intel Product<br /> Security.<br /> <br /> (cherry picked from commit 9284ab3b6e776c315883ac2611283d263c9460fd)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/i915/vrr: require valid min/max vfreq for VRR<br /> <br /> Ensure the EDID provided min/max vfreq are valid. Most scenarios are<br /> already covered (by coincidence) through the checks in<br /> intel_vrr_is_capable() and intel_vrr_is_in_range(), but be more explicit<br /> about it. At worst, a zero min_vfreq could lead to a division by zero in<br /> intel_vrr_compute_vmax().<br /> <br /> Discovered using AI-assisted static analysis confirmed by Intel Product<br /> Security.<br /> <br /> (cherry picked from commit 1765cf59f517b02f3b0591fe5120930d08bddeb6)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu/gfx11: 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 daa62107452d2451787c4248ca38fa2d1a0cbefd)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu/sdma5.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 8d144a0eb09537055841af48c9e7c2d4cd48e84d)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu/sdma5.2: 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 ae658afc7f47f6147371ec42cc6b1a793dfdb5af)

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 />