Page 301 of 3670 results (0.017 seconds)

CVSS: 6.2EPSS: 0%CPEs: 3EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: drm/msm/a6xx: Allocate enough space for GMU registers In commit 142639a52a01 ("drm/msm/a6xx: fix crashstate capture for A650") we changed a6xx_get_gmu_registers() to read 3 sets of registers. Unfortunately, we didn't change the memory allocation for the array. That leads to a KASAN warning (this was on the chromeos-5.4 kernel, which has the problematic commit backported to it): BUG: KASAN: slab-out-of-bounds in _a6xx_get_gmu_registers+0x144/0x430 Write of size 8 at addr ffffff80c89432b0 by task A618-worker/209 CPU: 5 PID: 209 Comm: A618-worker Tainted: G W 5.4.156-lockdep #22 Hardware name: Google Lazor Limozeen without Touchscreen (rev5 - rev8) (DT) Call trace: dump_backtrace+0x0/0x248 show_stack+0x20/0x2c dump_stack+0x128/0x1ec print_address_description+0x88/0x4a0 __kasan_report+0xfc/0x120 kasan_report+0x10/0x18 __asan_report_store8_noabort+0x1c/0x24 _a6xx_get_gmu_registers+0x144/0x430 a6xx_gpu_state_get+0x330/0x25d4 msm_gpu_crashstate_capture+0xa0/0x84c recover_worker+0x328/0x838 kthread_worker_fn+0x32c/0x574 kthread+0x2dc/0x39c ret_from_fork+0x10/0x18 Allocated by task 209: __kasan_kmalloc+0xfc/0x1c4 kasan_kmalloc+0xc/0x14 kmem_cache_alloc_trace+0x1f0/0x2a0 a6xx_gpu_state_get+0x164/0x25d4 msm_gpu_crashstate_capture+0xa0/0x84c recover_worker+0x328/0x838 kthread_worker_fn+0x32c/0x574 kthread+0x2dc/0x39c ret_from_fork+0x10/0x18 En el kernel de Linux, se resolvió la siguiente vulnerabilidad: drm/msm/a6xx: asigne suficiente espacio para los registros GMU. En el commit 142639a52a01 ("drm/msm/a6xx: corrija la captura del estado de falla para A650") cambiamos a6xx_get_gmu_registers() para que diga 3 conjuntos de registros. Desafortunadamente, no cambiamos la asignación de memoria para la matriz. • https://git.kernel.org/stable/c/142639a52a01e90c512a9a8d2156997e02a65b53 https://git.kernel.org/stable/c/d646856a600e8635ba498f20b194219b158626e8 https://git.kernel.org/stable/c/83e54fcf0b14ca2d869dd37abe1bb6542805f538 https://git.kernel.org/stable/c/b4d25abf9720b69a03465b09d0d62d1998ed6708 • CWE-787: Out-of-bounds Write •

CVSS: 4.1EPSS: 0%CPEs: 2EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: drm/vc4: kms: Add missing drm_crtc_commit_put Commit 9ec03d7f1ed3 ("drm/vc4: kms: Wait on previous FIFO users before a commit") introduced a global state for the HVS, with each FIFO storing the current CRTC commit so that we can properly synchronize commits. However, the refcounting was off and we thus ended up leaking the drm_crtc_commit structure every commit. Add a drm_crtc_commit_put to prevent the leakage. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: drm/vc4: kms: agregar drm_crtc_commit_put faltante el commit 9ec03d7f1ed3 ("drm/vc4: kms: esperar a los usuarios FIFO anteriores antes de una confirmación") introdujo un estado global para HVS, con cada FIFO almacena El commit CRTC actual para que podamos sincronizar correctamente las confirmaciones. Sin embargo, el recuento no se realizó y, por lo tanto, terminamos filtrando la estructura drm_crtc_commit en cada confirmación. Agregue un drm_crtc_commit_put para evitar la fuga. • https://git.kernel.org/stable/c/9ec03d7f1ed394897891319a4dda75f52c5d292d https://git.kernel.org/stable/c/53f9601e908d42481addd67cdb01a9288c611124 https://git.kernel.org/stable/c/049cfff8d53a30cae3349ff71a4c01b7d9981bc2 •

CVSS: -EPSS: 0%CPEs: 2EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: drm/vc4: kms: Clear the HVS FIFO commit pointer once done Commit 9ec03d7f1ed3 ("drm/vc4: kms: Wait on previous FIFO users before a commit") introduced a wait on the previous commit done on a given HVS FIFO. However, we never cleared that pointer once done. Since drm_crtc_commit_put can free the drm_crtc_commit structure directly if we were the last user, this means that it can lead to a use-after free if we were to duplicate the state, and that stale pointer would even be copied to the new state. Set the pointer to NULL once we're done with the wait so that we don't carry over a pointer to a free'd structure. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/vc4: kms: borre el puntero de commit FIFO de HVS una vez realizado. El commit 9ec03d7f1ed3 ("drm/vc4: kms: espere a los usuarios FIFO anteriores antes de una confirmación") introdujo una espera en el commit anterior realizada en un HVS FIFO determinado. Sin embargo, nunca borramos ese puntero una vez hecho. • https://git.kernel.org/stable/c/9ec03d7f1ed394897891319a4dda75f52c5d292d https://git.kernel.org/stable/c/2931db9a5ed219546cf2ae0546698faf78281b89 https://git.kernel.org/stable/c/d134c5ff71c7f2320fc7997f2fbbdedf0c76889a •

CVSS: -EPSS: 0%CPEs: 2EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: drm/msm/devfreq: Fix OPP refcnt leak En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/msm/devfreq: corrige la fuga de referencia de OPP • https://git.kernel.org/stable/c/9bc95570175a7fbca29d86d22c54bbf399f4ad5a https://git.kernel.org/stable/c/a4eb55901df1dce8c6944438bbdf57caf08911e2 https://git.kernel.org/stable/c/59ba1b2b4825342676300f66d785764be3fcb093 •

CVSS: -EPSS: 0%CPEs: 2EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: drm/msm: Fix mmap to include VM_IO and VM_DONTDUMP In commit 510410bfc034 ("drm/msm: Implement mmap as GEM object function") we switched to a new/cleaner method of doing things. That's good, but we missed a little bit. Before that commit, we used to _first_ run through the drm_gem_mmap_obj() case where `obj->funcs->mmap()` was NULL. That meant that we ran: vma->vm_flags |= VM_IO | VM_PFNMAP | VM_DONTEXPAND | VM_DONTDUMP; vma->vm_page_prot = pgprot_writecombine(vm_get_page_prot(vma->vm_flags)); vma->vm_page_prot = pgprot_decrypted(vma->vm_page_prot); ...and _then_ we modified those mappings with our own. Now that `obj->funcs->mmap()` is no longer NULL we don't run the default code. It looks like the fact that the vm_flags got VM_IO / VM_DONTDUMP was important because we're now getting crashes on Chromebooks that use ARC++ while logging out. • https://git.kernel.org/stable/c/510410bfc034c57cc3caf1572aa47c1017bab2f9 https://git.kernel.org/stable/c/8e2b7fe5e8a4be5e571561d9afcfbd92097288ba https://git.kernel.org/stable/c/3466d9e217b337bf473ee629c608e53f9f3ab786 •