🚨 CVE-2026-68232
In the Linux kernel, the following vulnerability has been resolved:

drm/gpusvm: Fix MM reference leak in drm_gpusvm_range_evict

If kvmalloc_array() fails in drm_gpusvm_range_evict(), the MM
reference acquired earlier is not released, resulting in a reference
leak.

Fix this by dropping the MM reference on the kvmalloc_array()
failure path.

🎖@cveNotify

🚨 CVE-2026-68233
In the Linux kernel, the following vulnerability has been resolved:

drm/vc4: Shut down BO cache timer before teardown

The BO cache timer callback schedules time_work, and time_work can rearm
the timer through vc4_bo_cache_free_old().

vc4_bo_cache_destroy() deletes the timer and then cancels the work, which
does not break that cycle: the work being cancelled can rearm the timer,
and the timer then queues work again after teardown.

Use timer_shutdown_sync() instead, so the timer cannot be rearmed and the
cycle ends with cancel_work_sync().

🎖@cveNotify

🚨 CVE-2026-68234
In the Linux kernel, the following vulnerability has been resolved:

drm/amdgpu: fix bo->pin leaking in amdgpu_bo_create_reserved

amdgpu_bo_create_reserved() only allocates a new BO when
*bo_ptr (struct amdgpu_bo **bo_ptr as input parameter) is
NULL, it simply skips creation when *bo_ptr is non-NULL.
But it unconditionally reserves, pins, gart allocates
and maps the BO afterwards.

When the same non-NULL BO pointer is passed in again,
for example firmware buffers that live in adev and are
re-loaded on every resume / cp_resume / start
under AMDGPU_FW_LOAD_DIRECT, amdgpu_bo_pin() just increases
pin_count unconditionally, however the matching teardown only unpins
once, so pin_count never drops to zero, so TTM is not able
to move, swap or evict a BO, causing BO leaks.

This commit fixes this issue by only pinning the bo
once at creation, and repeated calls no longer
take additional pin references.

(cherry picked from commit 3ddc0ae76202c447b6aec61e907b852bc94671cf)

🎖@cveNotify

🚨 CVE-2026-68235
In the Linux kernel, the following vulnerability has been resolved:

drm/amd/display: dce100: skip non-DP stream encoders for DP MST

On DCE8-class ASICs (e.g. Bonaire), the resource pool contains digital
DIG stream encoders plus one analog DAC encoder. When assigning a stream
encoder for a second DisplayPort MST stream, if the preferred digital
encoder is already acquired, dce100_find_first_free_match_stream_enc_for_link()
falls back to the first free pool entry. That entry may be the analog
encoder, whose funcs table lacks DP hooks such as dp_set_stream_attribute.
The subsequent atomic commit then dereferences NULL function pointers in
link_set_dpms_on() and crashes.

Skip encoders without dp_set_stream_attribute when the stream uses a DP
signal (including MST). Use dc_is_dp_signal(stream->signal) for the MST
fallback path instead of checking only the link connector signal.

Tested on:
- GPU: AMD Radeon R7 260X (Bonaire / DCE8)
- Board: Supermicro C9X299-PG300
- Setup: DP MST daisy chain, hotplug second monitor or have it connected on boot
- Kernel: 7.1.3 (issue observed since 6.19)
- Result: kernel oops without patch; dual monitors stable with patch

(cherry picked from commit 28ec64943e3ee4d9b8d30cea61e380f1429953a8)

🎖@cveNotify

🚨 CVE-2026-68236
In the Linux kernel, the following vulnerability has been resolved:

drm/amd/display: set new_stream to NULL after release

In dm_update_crtc_state(), the skip_modeset path releases new_stream
via dc_stream_release() but does not set the pointer to NULL.

If a later error (e.g., color management failure) triggers the fail
label, the error path calls dc_stream_release() again on the same
dangling pointer, causing a double release and potential use-after-free.

Fix this by setting new_stream to NULL after the initial release.

(cherry picked from commit 99f3af19073b3ddbfd96e789124cce12c4277b28)

🎖@cveNotify

🚨 CVE-2026-68237
In the Linux kernel, the following vulnerability has been resolved:

drm/amdgpu/userq: fix indefinite fence wait during GPU reset

pre_reset only force-completes fences of MAPPED queues. A queue in any
other state (e.g. mid-eviction) keeps its last_fence pending; after a
GPU reset that fence never signals, so the eviction/suspend worker and
process teardown (amdgpu_evf_mgr_flush_suspend) wait on it forever and
wedge the machine:

INFO: task kworker/6:28 blocked for more than 120 seconds.
Workqueue: events amdgpu_eviction_fence_suspend_worker [amdgpu]
Call Trace:
dma_fence_wait_timeout+0x7e/0x130
amdgpu_userq_evict+0x67/0x140 [amdgpu]
amdgpu_eviction_fence_suspend_worker+0xd8/0x160 [amdgpu]
process_scheduled_works+0xa6/0x420

Force-complete every queue's fence regardless of state. The unmap and
mark-hung step stays gated on MAPPED, since unmapping a queue that is
not mapped is invalid.

(cherry picked from commit 9102b39fa924dcc3dc75a3137bfa9633c40b88c0)

🎖@cveNotify

🚨 CVE-2026-68239
In the Linux kernel, the following vulnerability has been resolved:

drm/ttm: Account for NULL and handle pages in ttm_pool_backup

Pages in ttm_pool_backup can be NULL or backup handles
(ttm_backup_page_ptr_is_handle()), neither of which can be passed to
set_pages_array_wb() or freed. Add a dedicated WB pass before the
dma/purge loop that walks allocations using the same i += num_pages
stride, skipping NULL and handle entries, and calls set_pages_array_wb()
once per contiguous run of real pages. Apply the same NULL/handle guard
to the dma/purge loop.

Fixes the following oops:

Oops: general protection fault, kernel NULL pointer dereference 0x0: 0000 [#1] SMP NOPTI
RIP: 0010:__cpa_process_fault+0xf8/0x770
RSP: 0018:ffffc90000a87718 EFLAGS: 00010287
RAX: 0000000000000000 RBX: ffffc90000a87868 RCX: 0000000000000000
RDX: 0000000000001000 RSI: 0005088000000000 RDI: ffffffff827c5f34
RBP: 0005088000000000 R08: ffffc90000a877cb R09: ffffc90000a877d0
R10: 0000000000000000 R11: 000000000000001b R12: 000ffffffffff000
R13: ffffc90000a87868 R14: ffffc90000a87868 R15: ffff88815b882ae0
FS: 0000000000000000(0000) GS:ffff8884ec840000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f930b844000 CR3: 000000000262e003 CR4: 0000000008f70ef0
PKRU: 55555554
Call Trace:
<TASK>
__change_page_attr_set_clr+0x989/0xe90
? __purge_vmap_area_lazy+0x6c/0x3a0
? _vm_unmap_aliases+0x250/0x2a0
set_pages_array_wb+0x7f/0x120
ttm_pool_backup+0x4c9/0x5b0 [ttm]
? dma_resv_wait_timeout+0x3b/0xf0
ttm_tt_backup+0x32/0x60 [ttm]
ttm_bo_shrink+0x66/0x110 [ttm]
xe_bo_shrink_purge+0x12b/0x1b0 [xe]
xe_bo_shrink+0xbb/0x270 [xe]
__xe_shrinker_walk+0xf7/0x160 [xe]
xe_shrinker_walk+0x9d/0xc0 [xe]
xe_shrinker_scan+0x11f/0x210 [xe]
do_shrink_slab+0x13b/0x270
shrink_slab+0xf1/0x400
shrink_node+0x352/0x8a0
balance_pgdat+0x32c/0x700
kswapd+0x205/0x2f0
? __pfx_autoremove_wake_function+0x10/0x10
? __pfx_kswapd+0x10/0x10
kthread+0xd1/0x110
? __pfx_kthread+0x10/0x10
ret_from_fork+0x1b1/0x200
? __pfx_kthread+0x10/0x10
ret_from_fork_asm+0x1a/0x30
</TASK>

🎖@cveNotify

🚨 CVE-2026-68240
In the Linux kernel, the following vulnerability has been resolved:

drm/gpusvm: publish dpagemap early to avoid device mapping leak on error

drm_gpusvm_get_pages() only stored the local dpagemap into
svm_pages->dpagemap on the success path. If a later page failed (e.g.
-EOPNOTSUPP when ctx->allow_mixed is false) and jumped to err_unmap,
svm_pages->dpagemap was still NULL, so __drm_gpusvm_unmap_pages() skipped
device_unmap() and leaked the device mappings already created.

Assign svm_pages->dpagemap when the first device page is mapped so the
err_unmap path can device_unmap() those mappings.

This issue was found by Sashiko AI review.

🎖@cveNotify

🚨 CVE-2026-68241
In the Linux kernel, the following vulnerability has been resolved:

drm/i915/mst: limit DP MST ESI service loop

The loop in intel_dp_check_mst_status() keeps servicing interrupts
originating from the sink without bound. Add an upper bound to the new
interrupts occurring during interrupt processing to not get stuck on
potentially stuck sink devices. Use arbitrary 32 tries to clear incoming
interrupts in one go.

Discovered using AI-assisted static analysis confirmed by Intel Product
Security.

Note: The condition likely pre-dates the commit in the Fixes: tag, but
this is about as far back as a backport has any chance of
succeeding. Before that, the retry had a goto.

(cherry picked from commit b4ea5272133059acb493cc36599071a9e852ec2e)

🎖@cveNotify

🚨 CVE-2026-68242
In the Linux kernel, the following vulnerability has been resolved:

drm/i915/gt: Fix NULL deref on sched_engine alloc failure

Avoid using intel_context_put() before intel_context_init() in
execlists_create_virtual() as the kref_put() inside would lead
to NULL deref on the IOCTL path when sched_engine allocation fails.

Discovered using AI-assisted static analysis confirmed by
Intel Product Security.

(cherry picked from commit 4f2a12f2d50e9f48227656e4dcbd6423506be31d)

🎖@cveNotify

🚨 CVE-2026-68243
In the Linux kernel, the following vulnerability has been resolved:

drm/i915/gem: Fix NULL deref in I915_CONTEXT_PARAM_SSEU

Setting context engine slot N into I915_ENGINE_CLASS_INVALID /
I915_ENGINE_CLASS_INVALID_NONE and attempting to apply
I915_CONTEXT_PARAM_SSEU to the same slot N will deref NULL.
Fix that.

Discovered using AI-assisted static analysis confirmed by
Intel Product Security.

(cherry picked from commit 36eda5b5c2d40da41cc0a5403c26986237cf9e87)

🎖@cveNotify

🚨 CVE-2026-68244
In the Linux kernel, the following vulnerability has been resolved:

drm/i915/gem: Do not leak siblings[] on proto context error

After a successful BALANCE/PARALLEL_SUBMIT extension on context
creation, error during processing of next user extension leaks
the siblings[] array. Fix that.

Discovered using AI-assisted static analysis confirmed by
Intel Product Security.

(cherry picked from commit aa65e0a4b51b3b54b53e4142aaa2d997aa1061ff)

🎖@cveNotify

🚨 CVE-2026-68245
In the Linux kernel, the following vulnerability has been resolved:

drm/amdgpu: fix lifetime issue of amdgpu_vm_get_task_info_pasid()

The vm pointer returned from amdgpu_vm_get_vm_from_pasid() is only
valid while the lock is still being held. Once xa_unlock_irqrestore is
called and returned, the pointer is no longer under lock and is subject
to modification. Since, the caller still dereferences vm->task_info in
amdgpu_vm_get_task_info_vm() after the lock is removed, this causes a
use after unlock problem.

Remove the lifetime issue present in amdgpu_vm_get_task_info_pasid()
through removing the amdgpu_vm_get_vm_from_pasid() function from
amdgpu_vm.c and making the relevant code inline to hold the lock while
it is still in use.

(cherry picked from commit 9d01579f3f868b333acc901815972685989092c7)

🎖@cveNotify

🚨 CVE-2026-68246
In the Linux kernel, the following vulnerability has been resolved:

drm/amdgpu/gfx11: replace BUG_ON() with WARN_ON()

There's no need to crash the kernel for these cases.

(cherry picked from commit daa62107452d2451787c4248ca38fa2d1a0cbefd)

🎖@cveNotify

🚨 CVE-2026-68247
In the Linux kernel, the following vulnerability has been resolved:

drm/i915/bios: range check LFP Data Block panel_type2

While the panel_type from LFP Data Block is range checked, panel_type2
is not. Add a few helpers for range checking, and use them to not only
check panel_type2, but also improve clarity and correctness in the panel
type selection.

Discovered using AI-assisted static analysis confirmed by Intel Product
Security.

v2:
- Fix commit message typo (Michał)
- Add is_panel_type_pnp() (Ville)

(cherry picked from commit c9ebe5d2f25729d6cfbbb1235d640bf67f9275df)

🎖@cveNotify

🚨 CVE-2026-68248
In the Linux kernel, the following vulnerability has been resolved:

drm/i915: Return NULL on error in active_instance

Avoid returning &node->base when node is NULL due to OOM
during GFP_ATOMIC allocation.

Discovered using AI-assisted static analysis confirmed by
Intel Product Security.

(cherry picked from commit 6029bc064f0b1bac184203a50fbaaf070fa18832)

🎖@cveNotify

🚨 CVE-2026-68249
In the Linux kernel, the following vulnerability has been resolved:

drm/amdgpu/sdma5.0: replace BUG_ON() with WARN_ON()

There's no need to crash the kernel for these cases.

(cherry picked from commit 8d144a0eb09537055841af48c9e7c2d4cd48e84d)

🎖@cveNotify

🚨 CVE-2026-68250
In the Linux kernel, the following vulnerability has been resolved:

drm/amdgpu/sdma5.2: replace BUG_ON() with WARN_ON()

There's no need to crash the kernel for these cases.

(cherry picked from commit ae658afc7f47f6147371ec42cc6b1a793dfdb5af)

🎖@cveNotify

🚨 CVE-2026-68251
In the Linux kernel, the following vulnerability has been resolved:

drm/amdgpu/sdma6.0: replace BUG_ON() with WARN_ON()

There's no need to crash the kernel for these cases.

(cherry picked from commit c17a508a7d652da3728f8bbc481bfffe96d65a87)

🎖@cveNotify

🚨 CVE-2026-68252
In the Linux kernel, the following vulnerability has been resolved:

drm/amdgpu/sdma7.0: replace BUG_ON() with WARN_ON()

There's no need to crash the kernel for these cases.

(cherry picked from commit 9723a8bed3aa251a26bee4583bac9d8fb064dd44)

🎖@cveNotify

🚨 CVE-2026-68253
In the Linux kernel, the following vulnerability has been resolved:

drm/i915/hdcp: check streams[] bounds before overflow

The data->streams[] overflow check is done after the buffer overflow has
already happened. Move the overflow check before the write.

Side note, emitting a warning splat with a backtrace might be overkill
here, but prefer not changing the behaviour other than not doing the
overrun.

Discovered using AI-assisted static analysis confirmed by Intel Product
Security.

(cherry picked from commit 9284ab3b6e776c315883ac2611283d263c9460fd)

🎖@cveNotify