Vulnerabilidades

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

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: detect_link_and_local_sink: DP alt mode timeout path leaks prev_sink reference<br /> <br /> prev_sink is unconditionally retained via dc_sink_retain at function<br /> entry, but the DP alt mode timeout path inside SIGNAL_TYPE_DISPLAY_PORT<br /> returns false without releasing prev_sink. All other return paths in the<br /> function correctly call dc_sink_release(prev_sink), making this the only<br /> missing cleanup.<br /> <br /> (cherry picked from commit 45510cf662dcf46b5d8926d454f338809f107b9d)

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/imagination: acquire vm_ctx-&gt;lock before mapping memory to GPU VM<br /> <br /> The drm gpuvm code doesn&amp;#39;t protect find operation against map operation,<br /> and the driver needs to ensure a map operation shouldn&amp;#39;t happen when a<br /> find operation is in progress.<br /> <br /> In some cases a find operation will be in progress when doing map/unmap<br /> operations, and the find operation will do a NULL pointer dereference.<br /> <br /> An example of the stack trace of such NULL dereference is shown below:<br /> <br /> ```<br /> Unable to handle kernel access to user memory without uaccess routines at<br /> virtual address 0000000000000010<br /> <br /> [] drm_gpuva_find+0x28/0x6c [drm_gpuvm]<br /> [] pvr_vm_unmap+0x34/0x68 [powervr]<br /> [] pvr_ioctl_vm_unmap+0x2e/0x50 [powervr]<br /> [] drm_ioctl_kernel+0x8e/0xdc<br /> [] drm_ioctl+0x1be/0x3e0<br /> [] __riscv_sys_ioctl+0xba/0xc4<br /> [] do_trap_ecall_u+0x23e/0x3f4<br /> [] handle_exception+0x168/0x174<br /> ```<br /> <br /> As all occurences of drm_gpuva_find*() are already guarded by<br /> vm_ctx-&gt;lock, make pvr_vm_map() to acquire this lock to prevent<br /> disturbing any find operation. This fixes the NULL deference problem in<br /> drm_gpuva_find*().

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/imagination: fix error checking of pvr_vm_context_lookup()<br /> <br /> Since pvr_vm_context_lookup() returns either NULL or a pointer, then stop<br /> using IS_ERR() for checking the return value.<br /> <br /> Using IS_ERR() leads to the kernel oops reported below. It can be<br /> reproduced by passing an invalid VM context handle from userspace to the<br /> DRM_IOCTL_PVR_CREATE_CONTEXT ioctl.<br /> <br /> [ 92.733119] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000148<br /> [ 92.742042] Mem abort info:<br /> [ 92.744890] ESR = 0x0000000096000004<br /> [ 92.748686] EC = 0x25: DABT (current EL), IL = 32 bits<br /> [ 92.754020] SET = 0, FnV = 0<br /> [ 92.757154] EA = 0, S1PTW = 0<br /> [ 92.760337] FSC = 0x04: level 0 translation fault<br /> [ 92.765243] Data abort info:<br /> [ 92.768129] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000<br /> [ 92.773626] CM = 0, WnR = 0, TnD = 0, TagAccess = 0<br /> [ 92.778763] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0<br /> [ 92.784098] user pgtable: 4k pages, 48-bit VAs, pgdp=000000088ed23000<br /> [ 92.790550] [0000000000000148] pgd=0000000000000000, p4d=0000000000000000<br /> [ 92.797381] Internal error: Oops: 0000000096000004 [#1] SMP<br /> [ 92.803027] Modules linked in: powervr<br /> [ 92.852533] CPU: 0 UID: 0 PID: 409 Comm: triangle Not tainted 7.1.0-rc5-g98b46e693b91 #1 PREEMPT<br /> [ 92.861385] Hardware name: Texas Instruments AM68 SK (DT)<br /> [ 92.866766] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> [ 92.873709] pc : pvr_vm_get_fw_mem_context+0x0/0xc [powervr]<br /> [ 92.879376] lr : pvr_queue_create+0x26c/0x440 [powervr]<br /> [ 92.884595] sp : ffff8000837fbb00<br /> [ 92.887895] x29: ffff8000837fbb60 x28: 0000000000000000 x27: ffff8000837fbce8<br /> [ 92.895015] x26: ffff000807f61a40 x25: ffff000807f61a00 x24: ffff000807f64400<br /> [ 92.902135] x23: ffff00080a5ab000 x22: ffff800079b24730 x21: ffff000807f61800<br /> [ 92.909254] x20: ffff00080999e680 x19: 0000000000000000 x18: 0000000000000000<br /> [ 92.916373] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000001<br /> [ 92.923492] x14: 0000000000000000 x13: 0000000000000002 x12: ffff80008145b298<br /> [ 92.930611] x11: ffff8000844e5000 x10: ffff80008165a130 x9 : 0000000000000100<br /> [ 92.937730] x8 : 0000000000000001 x7 : ffff0008076b27e0 x6 : ffff00080ec43b7c<br /> [ 92.944850] x5 : ffff00080ec43b78 x4 : 0000000000000000 x3 : ffff00080999e680<br /> [ 92.951968] x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000<br /> [ 92.959088] Call trace:<br /> [ 92.961521] pvr_vm_get_fw_mem_context+0x0/0xc [powervr] (P)<br /> [ 92.967173] pvr_context_create+0x190/0x410 [powervr]<br /> [ 92.972218] pvr_ioctl_create_context+0x44/0x8c [powervr]<br /> [ 92.977608] drm_ioctl_kernel+0xbc/0x124 [drm]<br /> [ 92.982127] drm_ioctl+0x1f8/0x4dc [drm]<br /> [ 92.986098] __arm64_sys_ioctl+0xac/0x104<br /> [ 92.990102] invoke_syscall+0x54/0x10c<br /> [ 92.993842] el0_svc_common.constprop.0+0x40/0xe0<br /> [ 92.998532] do_el0_svc+0x1c/0x28<br /> [ 93.001835] el0_svc+0x38/0x11c<br /> [ 93.004969] el0t_64_sync_handler+0xa0/0xe4<br /> [ 93.009139] el0t_64_sync+0x198/0x19c<br /> [ 93.012792] Code: aa1703e0 d2800014 95cb0ba4 17ffffe8 (f940a400)<br /> [ 93.018869] ---[ end trace 0000000000000000 ]---

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/imagination: Fix user array stride in pvr_set_uobj_array()<br /> <br /> pvr_set_uobj_array() copies an array of kernel objects to a userspace<br /> array whose element size is described by out-&gt;stride. When out-&gt;stride<br /> is different from the kernel object size, the slow path advances the<br /> userspace pointer by the kernel object size and the kernel pointer by the<br /> userspace stride.<br /> <br /> This reverses the intended layout. For larger userspace strides, later<br /> copies read from the wrong kernel addresses. For smaller userspace<br /> strides, later copies are written at the wrong userspace offsets. The<br /> padding clear is also done only for the first element instead of the<br /> padding area for each element.<br /> <br /> Advance the userspace pointer by out-&gt;stride and the kernel pointer by<br /> obj_size, and clear per-element padding while the current userspace<br /> pointer is still available.

*** 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)