Page 436 of 5172 results (0.011 seconds)

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

In the Linux kernel, the following vulnerability has been resolved: btrfs: do not BUG_ON in link_to_fixup_dir While doing error injection testing I got the following panic kernel BUG at fs/btrfs/tree-log.c:1862! invalid opcode: 0000 [#1] SMP NOPTI CPU: 1 PID: 7836 Comm: mount Not tainted 5.13.0-rc1+ #305 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.13.0-2.fc32 04/01/2014 RIP: 0010:link_to_fixup_dir+0xd5/0xe0 RSP: 0018:ffffb5800180fa30 EFLAGS: 00010216 RAX: fffffffffffffffb RBX: 00000000fffffffb RCX: ffff8f595287faf0 RDX: ffffb5800180fa37 RSI: ffff8f5954978800 RDI: 0000000000000000 RBP: ffff8f5953af9450 R08: 0000000000000019 R09: 0000000000000001 R10: 000151f408682970 R11: 0000000120021001 R12: ffff8f5954978800 R13: ffff8f595287faf0 R14: ffff8f5953c77dd0 R15: 0000000000000065 FS: 00007fc5284c8c40(0000) GS:ffff8f59bbd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fc5287f47c0 CR3: 000000011275e002 CR4: 0000000000370ee0 Call Trace: replay_one_buffer+0x409/0x470 ? btree_read_extent_buffer_pages+0xd0/0x110 walk_up_log_tree+0x157/0x1e0 walk_log_tree+0xa6/0x1d0 btrfs_recover_log_trees+0x1da/0x360 ? replay_one_extent+0x7b0/0x7b0 open_ctree+0x1486/0x1720 btrfs_mount_root.cold+0x12/0xea ? __kmalloc_track_caller+0x12f/0x240 legacy_get_tree+0x24/0x40 vfs_get_tree+0x22/0xb0 vfs_kern_mount.part.0+0x71/0xb0 btrfs_mount+0x10d/0x380 ? • https://git.kernel.org/stable/c/76bfd8ac20bebeae599452a03dfc5724c0475dcf https://git.kernel.org/stable/c/e934c4ee17b33bafb0444f2f9766cda7166d3c40 https://git.kernel.org/stable/c/0eaf383c6a4a83c09f60fd07a1bea9f1a9181611 https://git.kernel.org/stable/c/6eccfb28f8dca70c9b1b3bb3194ca54cbe73a9fa https://git.kernel.org/stable/c/0ed102453aa1cd12fefde8f6b60b9519b0b1f003 https://git.kernel.org/stable/c/7e13db503918820e6333811cdc6f151dcea5090a https://git.kernel.org/stable/c/b545442133580dcb2f2496133bf850824d41255c https://git.kernel.org/stable/c/91df99a6eb50d5a1bc70fff4a09a0b7ae •

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 •