Vulnerabilities

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 bo-&gt;pin leaking in amdgpu_bo_create_reserved<br /> <br /> amdgpu_bo_create_reserved() only allocates a new BO when<br /> *bo_ptr (struct amdgpu_bo **bo_ptr as input parameter) is<br /> NULL, it simply skips creation when *bo_ptr is non-NULL.<br /> But it unconditionally reserves, pins, gart allocates<br /> and maps the BO afterwards.<br /> <br /> When the same non-NULL BO pointer is passed in again,<br /> for example firmware buffers that live in adev and are<br /> re-loaded on every resume / cp_resume / start<br /> under AMDGPU_FW_LOAD_DIRECT, amdgpu_bo_pin() just increases<br /> pin_count unconditionally, however the matching teardown only unpins<br /> once, so pin_count never drops to zero, so TTM is not able<br /> to move, swap or evict a BO, causing BO leaks.<br /> <br /> This commit fixes this issue by only pinning the bo<br /> once at creation, and repeated calls no longer<br /> take additional pin references.<br /> <br /> (cherry picked from commit 3ddc0ae76202c447b6aec61e907b852bc94671cf)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: dce100: skip non-DP stream encoders for DP MST<br /> <br /> On DCE8-class ASICs (e.g. Bonaire), the resource pool contains digital<br /> DIG stream encoders plus one analog DAC encoder. When assigning a stream<br /> encoder for a second DisplayPort MST stream, if the preferred digital<br /> encoder is already acquired, dce100_find_first_free_match_stream_enc_for_link()<br /> falls back to the first free pool entry. That entry may be the analog<br /> encoder, whose funcs table lacks DP hooks such as dp_set_stream_attribute.<br /> The subsequent atomic commit then dereferences NULL function pointers in<br /> link_set_dpms_on() and crashes.<br /> <br /> Skip encoders without dp_set_stream_attribute when the stream uses a DP<br /> signal (including MST). Use dc_is_dp_signal(stream-&gt;signal) for the MST<br /> fallback path instead of checking only the link connector signal.<br /> <br /> Tested on:<br /> - GPU: AMD Radeon R7 260X (Bonaire / DCE8)<br /> - Board: Supermicro C9X299-PG300<br /> - Setup: DP MST daisy chain, hotplug second monitor or have it connected on boot<br /> - Kernel: 7.1.3 (issue observed since 6.19)<br /> - Result: kernel oops without patch; dual monitors stable with patch<br /> <br /> (cherry picked from commit 28ec64943e3ee4d9b8d30cea61e380f1429953a8)

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.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: cedrus: skip invalid H.264 reference list entries<br /> <br /> Cedrus consumes H.264 ref_pic_list0/ref_pic_list1 entries from the<br /> stateless slice control and later uses their indices to look up<br /> decode-&gt;dpb[] in _cedrus_write_ref_list().<br /> <br /> Rejecting such controls in cedrus_try_ctrl() would break existing<br /> userspace, since stateless H.264 reference lists may legitimately carry<br /> out-of-range indices for missing references. Instead, guard the actual<br /> DPB lookup in Cedrus and skip entries whose indices do not fit the fixed<br /> V4L2_H264_NUM_DPB_ENTRIES array.<br /> <br /> This keeps the fix local to the driver use site and avoids out-of-bounds<br /> reads from malformed or unsupported reference list entries.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: amlogic-c3: Add validations for ae and awb config<br /> <br /> Avoid invalid memory access if the zones_num is bigger than<br /> zone_weight.<br /> <br /> This patch fixes the following smatch errors:<br /> drivers/media/platform/amlogic/c3/isp/c3-isp-params.c:111 c3_isp_params_awb_wt() error: buffer overflow &amp;#39;cfg-&gt;zone_weight&amp;#39; 768 zone_weight&amp;#39; 768 zone_weight&amp;#39; 255 zone_weight&amp;#39; 255

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: airspy: Return queued buffers on start_streaming() failure<br /> <br /> The vb2 framework hands buffers to the driver via buf_queue() before<br /> calling start_streaming(). If start_streaming() returns an error<br /> without first returning those buffers via vb2_buffer_done(),<br /> vb2_start_streaming() fires WARN_ON(owned_by_drv_count) and the queued<br /> buffers leak.<br /> <br /> airspy_start_streaming() returned -ENODEV early when the USB device had<br /> been disconnected (s-&gt;udev == NULL) without returning any buffers that<br /> buf_queue() had already accepted. Take v4l2_lock first and jump to the<br /> existing err_clear_bit label, which already drains s-&gt;queued_bufs via<br /> vb2_buffer_done(..., VB2_BUF_STATE_QUEUED) before unlocking.<br /> <br /> This mirrors the uvcvideo fix in commit 4cf3b6fd54eb ("media: uvcvideo:<br /> Return queued buffers on start_streaming() failure").