CVSS: 5.5EPSS: 0%CPEs: 8EXPL: 0CVE-2024-38619 – usb-storage: alauda: Check whether the media is initialized
https://notcve.org/view.php?id=CVE-2024-38619
In the Linux kernel, the following vulnerability has been resolved: usb-storage: alauda: Check whether the media is initialized The member "uzonesize" of struct alauda_info will remain 0 if alauda_init_media() fails, potentially causing divide errors in alauda_read_data() and alauda_write_lba(). - Add a member "media_initialized" to struct alauda_info. - Change a condition in alauda_check_media() to ensure the first initialization. - Add an error check for the return value of alauda_init_media(). En el kernel de Linux, se resolvió la siguiente vulnerabilidad: usb-storage: alauda: compruebe si el medio está inicializado. El miembro "uzonesize" de la estructura alauda_info permanecerá 0 si alauda_init_media() falla, lo que podría provocar errores de división en alauda_read_data() y alauda_write_lba(). - Agregue un miembro "media_initialized" a la estructura alauda_info. - Cambiar una condición en alauda_check_media() para asegurar la primera inicialización. - Agregue una verificación de errores para el valor de retorno de alauda_init_media(). • https://git.kernel.org/stable/c/e80b0fade09ef1ee67b0898d480d4c588f124d5f https://git.kernel.org/stable/c/e0aab7b07a9375337847c9d74a5ec044071e01c8 https://git.kernel.org/stable/c/51fe16c058acb22f847e69bc598066ed0bcd5c15 https://git.kernel.org/stable/c/f68820f1256b21466ff094dd97f243b7e708f9c1 https://git.kernel.org/stable/c/3eee13ab67f65606faa66e0c3c729e4f514838fd https://git.kernel.org/stable/c/e0e2eec76920a133dd49a4fbe4656d83596a1361 https://git.kernel.org/stable/c/2cc32639ec347e3365075b130f9953ef16cb13f1 https://git.kernel.org/stable/c/24bff7f714bdff97c2a75a0ff6a368cdf • CWE-457: Use of Uninitialized Variable •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2021-47616 – RDMA: Fix use-after-free in rxe_queue_cleanup
https://notcve.org/view.php?id=CVE-2021-47616
In the Linux kernel, the following vulnerability has been resolved: RDMA: Fix use-after-free in rxe_queue_cleanup On error handling path in rxe_qp_from_init() qp->sq.queue is freed and then rxe_create_qp() will drop last reference to this object. qp clean up function will try to free this queue one time and it causes UAF bug. Fix it by zeroing queue pointer after freeing queue in rxe_qp_from_init(). En el kernel de Linux, se resolvió la siguiente vulnerabilidad: RDMA: corrige el use-after-free en rxe_queue_cleanup En la ruta de manejo de errores en rxe_qp_from_init() qp->sq.queue se libera y luego rxe_create_qp() eliminará la última referencia a este objeto. La función de limpieza qp intentará liberar esta cola una vez y provocará un error UAF. Solucionarlo poniendo a cero el puntero de la cola después de liberar la cola en rxe_qp_from_init(). • https://git.kernel.org/stable/c/514aee660df493cd673154a6ba6bab745ec47b8c https://git.kernel.org/stable/c/acb53e47db1fbc7cd37ab10b46388f045a76e383 https://git.kernel.org/stable/c/84b01721e8042cdd1e8ffeb648844a09cd4213e0 •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2021-47615 – RDMA/mlx5: Fix releasing unallocated memory in dereg MR flow
https://notcve.org/view.php?id=CVE-2021-47615
In the Linux kernel, the following vulnerability has been resolved: RDMA/mlx5: Fix releasing unallocated memory in dereg MR flow For the case of IB_MR_TYPE_DM the mr does doesn't have a umem, even though it is a user MR. This causes function mlx5_free_priv_descs() to think that it is a kernel MR, leading to wrongly accessing mr->descs that will get wrong values in the union which leads to attempt to release resources that were not allocated in the first place. For example: DMA-API: mlx5_core 0000:08:00.1: device driver tries to free DMA memory it has not allocated [device address=0x0000000000000000] [size=0 bytes] WARNING: CPU: 8 PID: 1021 at kernel/dma/debug.c:961 check_unmap+0x54f/0x8b0 RIP: 0010:check_unmap+0x54f/0x8b0 Call Trace: debug_dma_unmap_page+0x57/0x60 mlx5_free_priv_descs+0x57/0x70 [mlx5_ib] mlx5_ib_dereg_mr+0x1fb/0x3d0 [mlx5_ib] ib_dereg_mr_user+0x60/0x140 [ib_core] uverbs_destroy_uobject+0x59/0x210 [ib_uverbs] uobj_destroy+0x3f/0x80 [ib_uverbs] ib_uverbs_cmd_verbs+0x435/0xd10 [ib_uverbs] ? uverbs_finalize_object+0x50/0x50 [ib_uverbs] ? lock_acquire+0xc4/0x2e0 ? lock_acquired+0x12/0x380 ? • https://git.kernel.org/stable/c/f18ec422311767738ef4033b61e91cae07163b22 https://git.kernel.org/stable/c/e3bc4d4b50cae7db08e50dbe43f771c906e97701 https://git.kernel.org/stable/c/c44979ace49b4aede3cc7cb5542316e53a4005c9 https://git.kernel.org/stable/c/f0ae4afe3d35e67db042c58a52909e06262b740f •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2021-47614 – RDMA/irdma: Fix a user-after-free in add_pble_prm
https://notcve.org/view.php?id=CVE-2021-47614
In the Linux kernel, the following vulnerability has been resolved: RDMA/irdma: Fix a user-after-free in add_pble_prm When irdma_hmc_sd_one fails, 'chunk' is freed while its still on the PBLE info list. Add the chunk entry to the PBLE info list only after successful setting of the SD in irdma_hmc_sd_one. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: RDMA/irdma: corrige un user-after-free en add_pble_prm Cuando falla irdma_hmc_sd_one, el 'fragmento' se libera mientras todavía está en la lista de información de PBLE. Agregue la entrada del fragmento a la lista de información de PBLE solo después de configurar correctamente la SD en irdma_hmc_sd_one. • https://git.kernel.org/stable/c/e8c4dbc2fcacf5a7468d312168bb120c27c38b32 https://git.kernel.org/stable/c/11eebcf63e98fcf047a876a51d76afdabc3b8b9b https://git.kernel.org/stable/c/1e11a39a82e95ce86f849f40dda0d9c0498cebd9 •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2021-47613 – i2c: virtio: fix completion handling
https://notcve.org/view.php?id=CVE-2021-47613
In the Linux kernel, the following vulnerability has been resolved: i2c: virtio: fix completion handling The driver currently assumes that the notify callback is only received when the device is done with all the queued buffers. However, this is not true, since the notify callback could be called without any of the queued buffers being completed (for example, with virtio-pci and shared interrupts) or with only some of the buffers being completed (since the driver makes them available to the device in multiple separate virtqueue_add_sgs() calls). This can lead to incorrect data on the I2C bus or memory corruption in the guest if the device operates on buffers which are have been freed by the driver. (The WARN_ON in the driver is also triggered.) BUG kmalloc-128 (Tainted: G W ): Poison overwritten First byte 0x0 instead of 0x6b Allocated in i2cdev_ioctl_rdwr+0x9d/0x1de age=243 cpu=0 pid=28 memdup_user+0x2e/0xbd i2cdev_ioctl_rdwr+0x9d/0x1de i2cdev_ioctl+0x247/0x2ed vfs_ioctl+0x21/0x30 sys_ioctl+0xb18/0xb41 Freed in i2cdev_ioctl_rdwr+0x1bb/0x1de age=68 cpu=0 pid=28 kfree+0x1bd/0x1cc i2cdev_ioctl_rdwr+0x1bb/0x1de i2cdev_ioctl+0x247/0x2ed vfs_ioctl+0x21/0x30 sys_ioctl+0xb18/0xb41 Fix this by calling virtio_get_buf() from the notify handler like other virtio drivers and by actually waiting for all the buffers to be completed. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: i2c: virtio: manejo de finalización de reparación El controlador actualmente supone que la devolución de llamada de notificación solo se recibe cuando el dispositivo termina con todos los búferes en cola. Sin embargo, esto no es cierto, ya que la devolución de llamada de notificación podría llamarse sin que se complete ninguno de los búferes en cola (por ejemplo, con virtio-pci e interrupciones compartidas) o con solo algunos de los búferes completados (ya que el controlador los pone a disposición). al dispositivo en múltiples llamadas virtqueue_add_sgs() separadas). Esto puede provocar datos incorrectos en el bus I2C o daños en la memoria del huésped si el dispositivo funciona con búferes que han sido liberados por el controlador. • https://git.kernel.org/stable/c/3cfc88380413d20f777dc6648a38f683962e52bf https://git.kernel.org/stable/c/9cbb957441ed8873577d7d313a3d79d69f1dad5c https://git.kernel.org/stable/c/b503de239f62eca898cfb7e820d9a35499137d22 •