Page 513 of 5556 results (0.013 seconds)

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

In the Linux kernel, the following vulnerability has been resolved: drm/amd/amdgpu: fix refcount leak [Why] the gem object rfb->base.obj[0] is get according to num_planes in amdgpufb_create, but is not put according to num_planes [How] put rfb->base.obj[0] in amdgpu_fbdev_destroy according to num_planes En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/amdgpu: corrige la fuga de refcount [Por qué] el objeto gema rfb->base.obj[0] se obtiene según num_planes en amdgpufb_create, pero no se coloca según num_planes en amdgpufb_create num_planes [Cómo] poner rfb->base.obj[0] en amdgpu_fbdev_destroy según num_planes • https://git.kernel.org/stable/c/599e5d61ace952b0bb9bd942b198bbd0cfded1d7 https://git.kernel.org/stable/c/dde2656e0bbb2ac7d83a7bd95a8d5c3c95bbc009 https://git.kernel.org/stable/c/9fdb8ed37a3a44f9c49372b69f87fd5f61cb3240 https://git.kernel.org/stable/c/95a4ec905e51a30c64cf2d78b04a7acbeae5ca94 https://git.kernel.org/stable/c/fa7e6abc75f3d491bc561734312d065dc9dc2a77 •

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

In the Linux kernel, the following vulnerability has been resolved: net/smc: remove device from smcd_dev_list after failed device_add() If the device_add() for a smcd_dev fails, there's no cleanup step that rolls back the earlier list_add(). The device subsequently gets freed, and we end up with a corrupted list. Add some error handling that removes the device from the list. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: net/smc: eliminar dispositivo de smcd_dev_list después de fallar device_add() Si falla el dispositivo_add() para smcd_dev, no hay ningún paso de limpieza que revierta el list_add() anterior. Posteriormente, el dispositivo se libera y terminamos con una lista corrupta. Agregue algún manejo de errores que elimine el dispositivo de la lista. • https://git.kernel.org/stable/c/c6ba7c9ba43de1b57e9a53946e7ff988554c84ed https://git.kernel.org/stable/c/8b2cdc004d21a7255f219706dca64411108f7897 https://git.kernel.org/stable/c/40588782f1016c655ae1d302892f61d35af96842 https://git.kernel.org/stable/c/444d7be9532dcfda8e0385226c862fd7e986f607 •

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

In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Fix a use-after-free looks like we forget to set ttm->sg to NULL. Hit panic below [ 1235.844104] general protection fault, probably for non-canonical address 0x6b6b6b6b6b6b7b4b: 0000 [#1] SMP DEBUG_PAGEALLOC NOPTI [ 1235.989074] Call Trace: [ 1235.991751] sg_free_table+0x17/0x20 [ 1235.995667] amdgpu_ttm_backend_unbind.cold+0x4d/0xf7 [amdgpu] [ 1236.002288] amdgpu_ttm_backend_destroy+0x29/0x130 [amdgpu] [ 1236.008464] ttm_tt_destroy+0x1e/0x30 [ttm] [ 1236.013066] ttm_bo_cleanup_memtype_use+0x51/0xa0 [ttm] [ 1236.018783] ttm_bo_release+0x262/0xa50 [ttm] [ 1236.023547] ttm_bo_put+0x82/0xd0 [ttm] [ 1236.027766] amdgpu_bo_unref+0x26/0x50 [amdgpu] [ 1236.032809] amdgpu_amdkfd_gpuvm_alloc_memory_of_gpu+0x7aa/0xd90 [amdgpu] [ 1236.040400] kfd_ioctl_alloc_memory_of_gpu+0xe2/0x330 [amdgpu] [ 1236.046912] kfd_ioctl+0x463/0x690 [amdgpu] En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amdgpu: se soluciona un problema de use-after-free que parece que nos olvidamos de configurar ttm->sg en NULL. Se produce pánico a continuación [1235.844104] falla de protección general, probablemente para la dirección no canónica 0x6b6b6b6b6b6b7b4b: 0000 [#1] SMP DEBUG_PAGEALLOC NOPTI [1235.989074] Seguimiento de llamadas: [1235.991751] sg_free_table+0x17/0x20 [ 123 5.995667] amdgpu_ttm_backend_unbind.cold+0x4d/0xf7 [amdgpu] [ 1236.002288] amdgpu_ttm_backend_destroy+0x29/0x130 [amdgpu] [ 1236.008464] ttm_tt_destroy+0x1e/0x30 [ttm] [ 1236.013066] ttm_bo_cleanup_memtype_use+0x51/0xa 0 [ttm] [ 1236.018783] ttm_bo_release+0x262/0xa50 [ttm] [ 1236.023547] ttm_bo_put+0x82/0xd0 [ttm] [ 1236.027766] amdgpu_bo_unref+0x26/0x50 [amdgpu] [ 1236.032809] amdgpu_amdkfd_gpuvm_alloc_memory_of_gpu+0x7aa/0xd90 [amdgpu] [ 123 6.040400] kfd_ioctl_alloc_memory_of_gpu+0xe2/0x330 [amdgpu] [ 1236.046912] kfd_ioctl+0x463/0x690 [ amdgpu] • https://git.kernel.org/stable/c/0707c3fea8102d211631ba515ef2159707561b0d https://git.kernel.org/stable/c/3293cf3513d69f00c14d43e2020826d45ea0e46a https://git.kernel.org/stable/c/952ab3f9f48eb0e8050596d41951cf516be6b122 https://git.kernel.org/stable/c/a849e218556f932576c0fb1c5a88714b61709a17 https://git.kernel.org/stable/c/7398c2aab4da960761ec182d04d6d5abbb4a226e https://git.kernel.org/stable/c/f98cdf084405333ee2f5be548a91b2d168e49276 https://git.kernel.org/stable/c/d4ea141fd4b40636a8326df5a377d9c5cf9b3faa https://git.kernel.org/stable/c/1e5c37385097c35911b0f8a0c67ffd10e •

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

In the Linux kernel, the following vulnerability has been resolved: gve: Add NULL pointer checks when freeing irqs. When freeing notification blocks, we index priv->msix_vectors. If we failed to allocate priv->msix_vectors (see abort_with_msix_vectors) this could lead to a NULL pointer dereference if the driver is unloaded. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: gve: agrega comprobaciones de puntero NULL al liberar irqs. Al liberar bloques de notificaciones, indexamos priv->msix_vectors. Si no pudimos asignar priv->msix_vectors (consulte abort_with_msix_vectors), esto podría provocar una desreferencia del puntero NULL si el controlador está descargado. • https://git.kernel.org/stable/c/893ce44df56580fb878ca5af9c4a5fd87567da50 https://git.kernel.org/stable/c/821149ee88c206fa37e79c1868cc270518484876 https://git.kernel.org/stable/c/da21a35c00ff1a1794d4f166d3b3fa8db4d0f6fb https://git.kernel.org/stable/c/5278c75266c5094d3c0958793bf12fc90300e580 https://git.kernel.org/stable/c/5218e919c8d06279884aa0baf76778a6817d5b93 •

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

In the Linux kernel, the following vulnerability has been resolved: iommu/amd: Clear DMA ops when switching domain Since commit 08a27c1c3ecf ("iommu: Add support to change default domain of an iommu group") a user can switch a device between IOMMU and direct DMA through sysfs. This doesn't work for AMD IOMMU at the moment because dev->dma_ops is not cleared when switching from a DMA to an identity IOMMU domain. The DMA layer thus attempts to use the dma-iommu ops on an identity domain, causing an oops: # echo 0000:00:05.0 > /sys/sys/bus/pci/drivers/e1000e/unbind # echo identity > /sys/bus/pci/devices/0000:00:05.0/iommu_group/type # echo 0000:00:05.0 > /sys/sys/bus/pci/drivers/e1000e/bind ... BUG: kernel NULL pointer dereference, address: 0000000000000028 ... Call Trace: iommu_dma_alloc e1000e_setup_tx_resources e1000e_open Since iommu_change_dev_def_domain() calls probe_finalize() again, clear the dma_ops there like Vt-d does. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: iommu/amd: borra las operaciones de DMA al cambiar de dominio. Desde el commit 08a27c1c3ecf ("iommu: agrega soporte para cambiar el dominio predeterminado de un grupo iommu"), un usuario puede cambiar un dispositivo entre IOMMU y DMA directo a través de sysfs. • https://git.kernel.org/stable/c/08a27c1c3ecf5e1da193ce5f8fc97c3be16e75f0 https://git.kernel.org/stable/c/f3f2cf46291a693eab21adb94171b0128c2a9ec1 https://git.kernel.org/stable/c/d6177a6556f853785867e2ec6d5b7f4906f0d809 •