| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| In the Linux kernel, the following vulnerability has been resolved:
drm/sysfb: Avoid possible truncation with calculating visible size
Calculating the visible size of the system framebuffer can result in
truncation of the result. The calculation uses 32-bit arithmetics,
which can overflow if the values for height and stride are large. Fix
the issue by multiplying with mul_u32_u32(). |
| In the Linux kernel, the following vulnerability has been resolved:
drm/i915/gem: Add missing nospec on parallel submit slot
Add missing Spectre mitigation for userspace controlled parallel
submission slot.
Discovered using AI-assisted static analysis confirmed by Intel
Product Security.
(cherry picked from commit 15b9353deff3cf72331c387780de3cf9c316b643) |
| In the Linux kernel, the following vulnerability has been resolved:
drm/xe: Return error on non-migratable faults requiring devmem
Non-migratable faults that require devmem incorrectly jump to the 'out'
label, which squashes the error code intended to be returned to the
upper layers. Fix this by returning -EACCES instead.
(cherry picked from commit c4508edb2c723de93717272488ea65b165637eac) |
| In the Linux kernel, the following vulnerability has been resolved:
drm/xe/rtp: Add RING_FORCE_TO_NONPRIV_DENY to OA whitelists
Unconditionally whitelisting OA registers is a security violation. Set
RING_FORCE_TO_NONPRIV_DENY bit in OA nonpriv slots, so that OA registers
don't get whitelisted by default after probe, gt reset, resume and engine
reset.
(cherry picked from commit 90511bdcfda97211c01f1d945d4ea616578d8fca) |
| In the Linux kernel, the following vulnerability has been resolved:
drm/xe: Hold a dma-buf reference for imported BOs
An imported dma-buf BO is created as a ttm_bo_type_sg BO whose
reservation object is the exporter's dma_buf->resv. The importer,
however, only takes a dma-buf reference after a successful
dma_buf_dynamic_attach(). Until then nothing keeps the exporter alive,
so if the exporter is freed while the BO still references its resv, a
later access to that resv is a use-after-free:
Oops: general protection fault, probably for non-canonical address
0x6b6b6b6b6b6b6b9c
Workqueue: ttm ttm_bo_delayed_delete [ttm]
RIP: 0010:mutex_can_spin_on_owner+0x3f/0xc0
This can be reached on two paths:
- dma_buf_dynamic_attach() fails, or
- ttm_bo_init_reserved() fails during BO creation.
In both cases the BO already has bo->base.resv pointing at the exporter
resv, and sg BOs are always torn down via ttm_bo_delayed_delete(), which
locks bo->base.resv asynchronously - potentially after the exporter has
been freed.
Take the dma-buf reference in xe_bo_init_locked(), before
ttm_bo_init_reserved(), so it also covers a creation failure there, and
release it in xe_ttm_bo_destroy(). The reference is held for the whole
BO lifetime, keeping the shared resv alive on every path.
v2:
- Reworked the fix to avoid creating the imported sg BO before
dma_buf_dynamic_attach() succeeds.
- Attach with importer_priv == NULL and make invalidate_mappings ignore
incomplete imports.
v3:
- Dropped the xe-side reordering approach since importer_priv must be
valid when dma_buf_dynamic_attach() publishes the attachment.
- Per Christian's suggestion on the v1 thread, keyed the check on
import_attach rather than removing the sg guard entirely.
- Fixes both xe and amdgpu in a single TTM patch.
v4:
- Moved import_attach check to after dma_resv_copy_fences() so fences
are copied before returning for successful imports (Thomas).
- Removed exporter-alive claim from commit message (Thomas).
v5:
- Add drm/xe patch to keep imported sg BOs off the LRU before attach
succeeds; the TTM fix alone is not sufficient for xe if the BO is
already LRU-visible. (Thomas)
v4 patch:
https://patchwork.freedesktop.org/patch/736663/?series=169129&rev=2
- Patch 1 (drm/ttm) carries Christian's Reviewed-by from v4.
v6:
- Reworked the fix based on Thomas' suggestion. Instead of the TTM resv
individualization (v1-v5) plus the xe off-LRU/placement handling (v5),
just hold a dma-buf reference for the imported BO lifetime so the
shared resv can never be freed while the BO still references it.
Single xe patch, no TTM change. (Thomas)
- Take the reference in xe_bo_init_locked() before ttm_bo_init_reserved()
so a TTM creation failure is covered too (Thomas).
- Dropped the v5 series (drm/ttm + drm/xe off-LRU); the off-LRU approach
also regressed in CI BAT via ttm_bo_pipeline_gutting() creating a ghost
BO that outlived the exporter.
Link to v5: https://patchwork.freedesktop.org/series/169984/
v7:
- Move changelog above --- so it stays in the commit message.
- Reorder changelog entries oldest-to-newest. (Thomas)
(cherry picked from commit 3516f3fae6be35642f8f06f8a218da6425c0306a) |
| In the Linux kernel, the following vulnerability has been resolved:
drm/xe/vm: Fix BO prefetch with CONSULT_MEM_ADVISE_PREF_LOC
When prefetch region is DRM_XE_CONSULT_MEM_ADVISE_PREF_LOC for a BO VMA,
the code used it as an index into region_to_mem_type[], causing an
out-of-bounds access since the value is -1.
Resolve the preferred location for BO VMAs directly: local VRAM on dGFX
(using the BO's tile placement) or system memory on iGPU.
Discovered using AI-assisted static analysis confirmed by Intel Product
Security.
v2:
-Fix null dereference
(cherry picked from commit d9a4906ac03be9f6ed3f3b45c56c866b867fd75b) |
| In the Linux kernel, the following vulnerability has been resolved:
drm/xe/pt: Reset current_op in xe_pt_update_ops_init()
xe_pt_update_ops_init() fails to reset current_op to 0. On the
vm_bind path, ops_execute() calls xe_pt_update_ops_prepare() inside
the xe_validation_guard() / drm_exec_until_all_locked() loop. When
that loop retries due to lock contention or OOM eviction
(drm_exec_retry_on_contention() / xe_validation_retry_on_oom()),
xe_pt_update_ops_prepare() runs again on the same vops, and each
call to bind_op_prepare() increments current_op without resetting it.
After N retries current_op exceeds the array size allocated by
xe_vma_ops_alloc(), causing an out-of-bounds write into
SLUB-poisoned memory and a subsequent UAF crash in
xe_migrate_update_pgtables_cpu() when reading the corrupted pt_op->bind.
Also reset needs_svm_lock and needs_invalidation which are derived in
the same prepare pass and would otherwise cause wrong migrate ops
selection and redundant TLB invalidation on retry.
Fix this by resetting current_op, needs_svm_lock and needs_invalidation
in xe_pt_update_ops_init().
v2 (Matt):
- Add details in commit message.
- Add Fixes tag and Cc to stable@vger.kernel.org
(cherry picked from commit 046045543e530605c441063535e7dca0075369a6) |
| In the Linux kernel, the following vulnerability has been resolved:
drm/imagination: Fix user array stride in pvr_set_uobj_array()
pvr_set_uobj_array() copies an array of kernel objects to a userspace
array whose element size is described by out->stride. When out->stride
is different from the kernel object size, the slow path advances the
userspace pointer by the kernel object size and the kernel pointer by the
userspace stride.
This reverses the intended layout. For larger userspace strides, later
copies read from the wrong kernel addresses. For smaller userspace
strides, later copies are written at the wrong userspace offsets. The
padding clear is also done only for the first element instead of the
padding area for each element.
Advance the userspace pointer by out->stride and the kernel pointer by
obj_size, and clear per-element padding while the current userspace
pointer is still available. |
| In the Linux kernel, the following vulnerability has been resolved:
drm/imagination: fix error checking of pvr_vm_context_lookup()
Since pvr_vm_context_lookup() returns either NULL or a pointer, then stop
using IS_ERR() for checking the return value.
Using IS_ERR() leads to the kernel oops reported below. It can be
reproduced by passing an invalid VM context handle from userspace to the
DRM_IOCTL_PVR_CREATE_CONTEXT ioctl.
[ 92.733119] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000148
[ 92.742042] Mem abort info:
[ 92.744890] ESR = 0x0000000096000004
[ 92.748686] EC = 0x25: DABT (current EL), IL = 32 bits
[ 92.754020] SET = 0, FnV = 0
[ 92.757154] EA = 0, S1PTW = 0
[ 92.760337] FSC = 0x04: level 0 translation fault
[ 92.765243] Data abort info:
[ 92.768129] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000
[ 92.773626] CM = 0, WnR = 0, TnD = 0, TagAccess = 0
[ 92.778763] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
[ 92.784098] user pgtable: 4k pages, 48-bit VAs, pgdp=000000088ed23000
[ 92.790550] [0000000000000148] pgd=0000000000000000, p4d=0000000000000000
[ 92.797381] Internal error: Oops: 0000000096000004 [#1] SMP
[ 92.803027] Modules linked in: powervr
[ 92.852533] CPU: 0 UID: 0 PID: 409 Comm: triangle Not tainted 7.1.0-rc5-g98b46e693b91 #1 PREEMPT
[ 92.861385] Hardware name: Texas Instruments AM68 SK (DT)
[ 92.866766] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[ 92.873709] pc : pvr_vm_get_fw_mem_context+0x0/0xc [powervr]
[ 92.879376] lr : pvr_queue_create+0x26c/0x440 [powervr]
[ 92.884595] sp : ffff8000837fbb00
[ 92.887895] x29: ffff8000837fbb60 x28: 0000000000000000 x27: ffff8000837fbce8
[ 92.895015] x26: ffff000807f61a40 x25: ffff000807f61a00 x24: ffff000807f64400
[ 92.902135] x23: ffff00080a5ab000 x22: ffff800079b24730 x21: ffff000807f61800
[ 92.909254] x20: ffff00080999e680 x19: 0000000000000000 x18: 0000000000000000
[ 92.916373] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000001
[ 92.923492] x14: 0000000000000000 x13: 0000000000000002 x12: ffff80008145b298
[ 92.930611] x11: ffff8000844e5000 x10: ffff80008165a130 x9 : 0000000000000100
[ 92.937730] x8 : 0000000000000001 x7 : ffff0008076b27e0 x6 : ffff00080ec43b7c
[ 92.944850] x5 : ffff00080ec43b78 x4 : 0000000000000000 x3 : ffff00080999e680
[ 92.951968] x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000
[ 92.959088] Call trace:
[ 92.961521] pvr_vm_get_fw_mem_context+0x0/0xc [powervr] (P)
[ 92.967173] pvr_context_create+0x190/0x410 [powervr]
[ 92.972218] pvr_ioctl_create_context+0x44/0x8c [powervr]
[ 92.977608] drm_ioctl_kernel+0xbc/0x124 [drm]
[ 92.982127] drm_ioctl+0x1f8/0x4dc [drm]
[ 92.986098] __arm64_sys_ioctl+0xac/0x104
[ 92.990102] invoke_syscall+0x54/0x10c
[ 92.993842] el0_svc_common.constprop.0+0x40/0xe0
[ 92.998532] do_el0_svc+0x1c/0x28
[ 93.001835] el0_svc+0x38/0x11c
[ 93.004969] el0t_64_sync_handler+0xa0/0xe4
[ 93.009139] el0t_64_sync+0x198/0x19c
[ 93.012792] Code: aa1703e0 d2800014 95cb0ba4 17ffffe8 (f940a400)
[ 93.018869] ---[ end trace 0000000000000000 ]--- |
| In the Linux kernel, the following vulnerability has been resolved:
drm/amdkfd: Check bounds on CRIU restore queue type and mqd size
We weren't checking whether the values provided in the private
data in kfd CRIU restore were within bounds.
For queue type, add a KFD_QUEUE_TYPE_MAX and ensure the provided
type is less than it.
For mqd_size, add new function mqd_size_from_queue_type and confirm
that the provided mqd_size matches expectations.
(cherry picked from commit f19d8086f6644083c913d70bfdeee20e1b6f46a5) |
| In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: detect_link_and_local_sink: DP alt mode timeout path leaks prev_sink reference
prev_sink is unconditionally retained via dc_sink_retain at function
entry, but the DP alt mode timeout path inside SIGNAL_TYPE_DISPLAY_PORT
returns false without releasing prev_sink. All other return paths in the
function correctly call dc_sink_release(prev_sink), making this the only
missing cleanup.
(cherry picked from commit 45510cf662dcf46b5d8926d454f338809f107b9d) |
| 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) |
| 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) |
| 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) |
| 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) |
| 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) |
| 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) |
| 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) |
| 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) |
| 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) |
