CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2021-47197 – net/mlx5e: nullify cq->dbg pointer in mlx5_debug_cq_remove()
https://notcve.org/view.php?id=CVE-2021-47197
In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: nullify cq->dbg pointer in mlx5_debug_cq_remove() Prior to this patch in case mlx5_core_destroy_cq() failed it proceeds to rest of destroy operations. mlx5_core_destroy_cq() could be called again by user and cause additional call of mlx5_debug_cq_remove(). cq->dbg was not nullify in previous call and cause the crash. Fix it by nullify cq->dbg pointer after removal. Also proceed to destroy operations only if FW return 0 for MLX5_CMD_OP_DESTROY_CQ command. general protection fault, probably for non-canonical address 0x2000300004058: 0000 [#1] SMP PTI CPU: 5 PID: 1228 Comm: python Not tainted 5.15.0-rc5_for_upstream_min_debug_2021_10_14_11_06 #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:lockref_get+0x1/0x60 Code: 5d e9 53 ff ff ff 48 8d 7f 70 e8 0a 2e 48 00 c7 85 d0 00 00 00 02 00 00 00 c6 45 70 00 fb 5d c3 c3 cc cc cc cc cc cc cc cc 53 <48> 8b 17 48 89 fb 85 d2 75 3d 48 89 d0 bf 64 00 00 00 48 89 c1 48 RSP: 0018:ffff888137dd7a38 EFLAGS: 00010206 RAX: 0000000000000000 RBX: ffff888107d5f458 RCX: 00000000fffffffe RDX: 000000000002c2b0 RSI: ffffffff8155e2e0 RDI: 0002000300004058 RBP: ffff888137dd7a88 R08: 0002000300004058 R09: ffff8881144a9f88 R10: 0000000000000000 R11: 0000000000000000 R12: ffff8881141d4000 R13: ffff888137dd7c68 R14: ffff888137dd7d58 R15: ffff888137dd7cc0 FS: 00007f4644f2a4c0(0000) GS:ffff8887a2d40000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000055b4500f4380 CR3: 0000000114f7a003 CR4: 0000000000170ea0 Call Trace: simple_recursive_removal+0x33/0x2e0 ? debugfs_remove+0x60/0x60 debugfs_remove+0x40/0x60 mlx5_debug_cq_remove+0x32/0x70 [mlx5_core] mlx5_core_destroy_cq+0x41/0x1d0 [mlx5_core] devx_obj_cleanup+0x151/0x330 [mlx5_ib] ? __pollwait+0xd0/0xd0 ? xas_load+0x5/0x70 ? xa_load+0x62/0xa0 destroy_hw_idr_uobject+0x20/0x80 [ib_uverbs] uverbs_destroy_uobject+0x3b/0x360 [ib_uverbs] uobj_destroy+0x54/0xa0 [ib_uverbs] ib_uverbs_cmd_verbs+0xaf2/0x1160 [ib_uverbs] ? • https://git.kernel.org/stable/c/4f7bddf8c5c01cac74373443b13a68e1c6723a94 https://git.kernel.org/stable/c/94b960b9deffc02fc0747afc01f72cc62ab099e3 https://git.kernel.org/stable/c/ed8aafea4fec9c654e63445236e0b505e27ed3a7 https://git.kernel.org/stable/c/471c492890557bd58f73314bb4ad85d5a8fd5026 https://git.kernel.org/stable/c/2ae38157080616a13a9fe3f0b4b6ec0070aa408a https://git.kernel.org/stable/c/76ded29d3fcda4928da8849ffc446ea46871c1c2 •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2021-47196 – RDMA/core: Set send and receive CQ before forwarding to the driver
https://notcve.org/view.php?id=CVE-2021-47196
In the Linux kernel, the following vulnerability has been resolved: RDMA/core: Set send and receive CQ before forwarding to the driver Preset both receive and send CQ pointers prior to call to the drivers and overwrite it later again till the mlx4 is going to be changed do not overwrite ibqp properties. This change is needed for mlx5, because in case of QP creation failure, it will go to the path of QP destroy which relies on proper CQ pointers. BUG: KASAN: use-after-free in create_qp.cold+0x164/0x16e [mlx5_ib] Write of size 8 at addr ffff8880064c55c0 by task a.out/246 CPU: 0 PID: 246 Comm: a.out Not tainted 5.15.0+ #291 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 Call Trace: dump_stack_lvl+0x45/0x59 print_address_description.constprop.0+0x1f/0x140 kasan_report.cold+0x83/0xdf create_qp.cold+0x164/0x16e [mlx5_ib] mlx5_ib_create_qp+0x358/0x28a0 [mlx5_ib] create_qp.part.0+0x45b/0x6a0 [ib_core] ib_create_qp_user+0x97/0x150 [ib_core] ib_uverbs_handler_UVERBS_METHOD_QP_CREATE+0x92c/0x1250 [ib_uverbs] ib_uverbs_cmd_verbs+0x1c38/0x3150 [ib_uverbs] ib_uverbs_ioctl+0x169/0x260 [ib_uverbs] __x64_sys_ioctl+0x866/0x14d0 do_syscall_64+0x3d/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xae Allocated by task 246: kasan_save_stack+0x1b/0x40 __kasan_kmalloc+0xa4/0xd0 create_qp.part.0+0x92/0x6a0 [ib_core] ib_create_qp_user+0x97/0x150 [ib_core] ib_uverbs_handler_UVERBS_METHOD_QP_CREATE+0x92c/0x1250 [ib_uverbs] ib_uverbs_cmd_verbs+0x1c38/0x3150 [ib_uverbs] ib_uverbs_ioctl+0x169/0x260 [ib_uverbs] __x64_sys_ioctl+0x866/0x14d0 do_syscall_64+0x3d/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xae Freed by task 246: kasan_save_stack+0x1b/0x40 kasan_set_track+0x1c/0x30 kasan_set_free_info+0x20/0x30 __kasan_slab_free+0x10c/0x150 slab_free_freelist_hook+0xb4/0x1b0 kfree+0xe7/0x2a0 create_qp.part.0+0x52b/0x6a0 [ib_core] ib_create_qp_user+0x97/0x150 [ib_core] ib_uverbs_handler_UVERBS_METHOD_QP_CREATE+0x92c/0x1250 [ib_uverbs] ib_uverbs_cmd_verbs+0x1c38/0x3150 [ib_uverbs] ib_uverbs_ioctl+0x169/0x260 [ib_uverbs] __x64_sys_ioctl+0x866/0x14d0 do_syscall_64+0x3d/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xae • https://git.kernel.org/stable/c/514aee660df493cd673154a6ba6bab745ec47b8c https://git.kernel.org/stable/c/b70e072feffa0ba5c41a99b9524b9878dee7748e https://git.kernel.org/stable/c/6cd7397d01c4a3e09757840299e4f114f0aa5fa0 •
CVSS: 5.5EPSS: 0%CPEs: 3EXPL: 0CVE-2021-47195 – spi: fix use-after-free of the add_lock mutex
https://notcve.org/view.php?id=CVE-2021-47195
In the Linux kernel, the following vulnerability has been resolved: spi: fix use-after-free of the add_lock mutex Commit 6098475d4cb4 ("spi: Fix deadlock when adding SPI controllers on SPI buses") introduced a per-controller mutex. But mutex_unlock() of said lock is called after the controller is already freed: spi_unregister_controller(ctlr) -> put_device(&ctlr->dev) -> spi_controller_release(dev) -> mutex_unlock(&ctrl->add_lock) Move the put_device() after the mutex_unlock(). En el kernel de Linux, se resolvió la siguiente vulnerabilidad: spi: corrige el use-after-free del mutex add_lock. El commit 6098475d4cb4 ("spi: corrige el punto muerto al agregar controladores SPI en buses SPI") introdujo un mutex por controlador. Pero mutex_unlock() de dicho bloqueo se llama después de que el controlador ya está liberado: spi_unregister_controller(ctlr) -> put_device(&ctlr->dev) -> spi_controller_release(dev) -> mutex_unlock(&ctrl->add_lock) Mueva put_device() después el mutex_unlock(). • https://git.kernel.org/stable/c/6098475d4cb48d821bdf453c61118c56e26294f0 https://git.kernel.org/stable/c/722ef19a161ce3fffb3d1b01ce2301c306639bdd https://git.kernel.org/stable/c/37330f37f6666c7739a44b2b6b95b047ccdbed2d https://git.kernel.org/stable/c/6c53b45c71b4920b5e62f0ea8079a1da382b9434 • CWE-416: Use After Free •
CVSS: 7.8EPSS: 0%CPEs: 8EXPL: 0CVE-2021-47194 – cfg80211: call cfg80211_stop_ap when switch from P2P_GO type
https://notcve.org/view.php?id=CVE-2021-47194
In the Linux kernel, the following vulnerability has been resolved: cfg80211: call cfg80211_stop_ap when switch from P2P_GO type If the userspace tools switch from NL80211_IFTYPE_P2P_GO to NL80211_IFTYPE_ADHOC via send_msg(NL80211_CMD_SET_INTERFACE), it does not call the cleanup cfg80211_stop_ap(), this leads to the initialization of in-use data. For example, this path re-init the sdata->assigned_chanctx_list while it is still an element of assigned_vifs list, and makes that linked list corrupt. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: cfg80211: llame a cfg80211_stop_ap cuando cambie del tipo P2P_GO. Si las herramientas del espacio de usuario cambian de NL80211_IFTYPE_P2P_GO a NL80211_IFTYPE_ADHOC mediante send_msg(NL80211_CMD_SET_INTERFACE), no llama a la limpieza cfg80211_ stop_ap(), esto lleva a la inicialización de datos en uso. Por ejemplo, esta ruta reinicia sdata->assigned_chanctx_list mientras todavía es un elemento de la lista asignada_vifs y corrompe esa lista vinculada. • https://git.kernel.org/stable/c/ac800140c20e7ae51117e71289065bedd4930fc2 https://git.kernel.org/stable/c/8f06bb8c216bcd172394f61e557727e691b4cb24 https://git.kernel.org/stable/c/0738cdb636c21ab552eaecf905efa4a6070e3ebc https://git.kernel.org/stable/c/4e458abbb4a523f1413bfe15c079cf4e24c15b21 https://git.kernel.org/stable/c/b8a045e2a9b234cfbc06cf36923886164358ddec https://git.kernel.org/stable/c/52affc201fc22a1ab9a59ef0ed641a9adfcb8d13 https://git.kernel.org/stable/c/7b97b5776daa0b39dbdadfea176f9cc0646d4a66 https://git.kernel.org/stable/c/5a9b671c8d74a3e1b999e7a0c7f366079 • CWE-665: Improper Initialization •
CVSS: 5.5EPSS: 0%CPEs: 2EXPL: 0CVE-2021-47193 – scsi: pm80xx: Fix memory leak during rmmod
https://notcve.org/view.php?id=CVE-2021-47193
In the Linux kernel, the following vulnerability has been resolved: scsi: pm80xx: Fix memory leak during rmmod Driver failed to release all memory allocated. This would lead to memory leak during driver removal. Properly free memory when the module is removed. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: scsi: pm80xx: se corrigió la pérdida de memoria durante rmmod, el controlador no pudo liberar toda la memoria asignada. Esto puede provocar una pérdida de memoria durante la eliminación del controlador. Se debe liberar correctamente la memoria cuando se retire el módulo. • https://git.kernel.org/stable/c/269a4311b15f68d24e816f43f123888f241ed13d https://git.kernel.org/stable/c/51e6ed83bb4ade7c360551fa4ae55c4eacea354b • CWE-401: Missing Release of Memory after Effective Lifetime •