CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2021-47202 – thermal: Fix NULL pointer dereferences in of_thermal_ functions
https://notcve.org/view.php?id=CVE-2021-47202
In the Linux kernel, the following vulnerability has been resolved: thermal: Fix NULL pointer dereferences in of_thermal_ functions of_parse_thermal_zones() parses the thermal-zones node and registers a thermal_zone device for each subnode. However, if a thermal zone is consuming a thermal sensor and that thermal sensor device hasn't probed yet, an attempt to set trip_point_*_temp for that thermal zone device can cause a NULL pointer dereference. Fix it. console:/sys/class/thermal/thermal_zone87 # echo 120000 > trip_point_0_temp ... Unable to handle kernel NULL pointer dereference at virtual address 0000000000000020 ... Call trace: of_thermal_set_trip_temp+0x40/0xc4 trip_point_temp_store+0xc0/0x1dc dev_attr_store+0x38/0x88 sysfs_kf_write+0x64/0xc0 kernfs_fop_write_iter+0x108/0x1d0 vfs_write+0x2f4/0x368 ksys_write+0x7c/0xec __arm64_sys_write+0x20/0x30 el0_svc_common.llvm.7279915941325364641+0xbc/0x1bc do_el0_svc+0x28/0xa0 el0_svc+0x14/0x24 el0_sync_handler+0x88/0xec el0_sync+0x1c0/0x200 While at it, fix the possible NULL pointer dereference in other functions as well: of_thermal_get_temp(), of_thermal_set_emul_temp(), of_thermal_get_trend(). • https://git.kernel.org/stable/c/828f4c31684da94ecf0b44a2cbd35bbede04f0bd https://git.kernel.org/stable/c/6a315471cb6a07f651e1d3adc8962730f4fcccac https://git.kernel.org/stable/c/0750f769b95841b34a9fe8c418dd792ff526bf86 https://git.kernel.org/stable/c/ef2590a5305e0b8e9342f84c2214aa478ee7f28e https://git.kernel.org/stable/c/96cfe05051fd8543cdedd6807ec59a0e6c409195 •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2021-47201 – iavf: free q_vectors before queues in iavf_disable_vf
https://notcve.org/view.php?id=CVE-2021-47201
In the Linux kernel, the following vulnerability has been resolved: iavf: free q_vectors before queues in iavf_disable_vf iavf_free_queues() clears adapter->num_active_queues, which iavf_free_q_vectors() relies on, so swap the order of these two function calls in iavf_disable_vf(). This resolves a panic encountered when the interface is disabled and then later brought up again after PF communication is restored. • https://git.kernel.org/stable/c/65c7006f234c9ede887d468f595f259a5c5cc552 https://git.kernel.org/stable/c/926e8c83d4c1c2dac0026637eb0d492df876489e https://git.kernel.org/stable/c/78638b47132244e3934dc5dc79f6372d5ce8e98c https://git.kernel.org/stable/c/9ef6589cac9a8c47f5544ccdf4c498093733bb3f https://git.kernel.org/stable/c/89f22f129696ab53cfbc608e0a2184d0fea46ac1 •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2021-47200 – drm/prime: Fix use after free in mmap with drm_gem_ttm_mmap
https://notcve.org/view.php?id=CVE-2021-47200
In the Linux kernel, the following vulnerability has been resolved: drm/prime: Fix use after free in mmap with drm_gem_ttm_mmap drm_gem_ttm_mmap() drops a reference to the gem object on success. If the gem object's refcount == 1 on entry to drm_gem_prime_mmap(), that drop will free the gem object, and the subsequent drm_gem_object_get() will be a UAF. Fix by grabbing a reference before calling the mmap helper. This issue was forseen when the reference dropping was adding in commit 9786b65bc61ac ("drm/ttm: fix mmap refcounting"): "For that to work properly the drm_gem_object_get() call in drm_gem_ttm_mmap() must be moved so it happens before calling obj->funcs->mmap(), otherwise the gem refcount would go down to zero." • https://git.kernel.org/stable/c/9786b65bc61acec63f923978c75e707afbb74bc7 https://git.kernel.org/stable/c/4f8e469a2384dfa4047145b0093126462cbb6dc0 https://git.kernel.org/stable/c/8244a3bc27b3efd057da154b8d7e414670d5044f •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2021-47199 – net/mlx5e: CT, Fix multiple allocations and memleak of mod acts
https://notcve.org/view.php?id=CVE-2021-47199
In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: CT, Fix multiple allocations and memleak of mod acts CT clear action offload adds additional mod hdr actions to the flow's original mod actions in order to clear the registers which hold ct_state. When such flow also includes encap action, a neigh update event can cause the driver to unoffload the flow and then reoffload it. Each time this happens, the ct clear handling adds that same set of mod hdr actions to reset ct_state until the max of mod hdr actions is reached. Also the driver never releases the allocated mod hdr actions and causing a memleak. Fix above two issues by moving CT clear mod acts allocation into the parsing actions phase and only use it when offloading the rule. The release of mod acts will be done in the normal flow_put(). backtrace: [<000000007316e2f3>] krealloc+0x83/0xd0 [<00000000ef157de1>] mlx5e_mod_hdr_alloc+0x147/0x300 [mlx5_core] [<00000000970ce4ae>] mlx5e_tc_match_to_reg_set_and_get_id+0xd7/0x240 [mlx5_core] [<0000000067c5fa17>] mlx5e_tc_match_to_reg_set+0xa/0x20 [mlx5_core] [<00000000d032eb98>] mlx5_tc_ct_entry_set_registers.isra.0+0x36/0xc0 [mlx5_core] [<00000000fd23b869>] mlx5_tc_ct_flow_offload+0x272/0x1f10 [mlx5_core] [<000000004fc24acc>] mlx5e_tc_offload_fdb_rules.part.0+0x150/0x620 [mlx5_core] [<00000000dc741c17>] mlx5e_tc_encap_flows_add+0x489/0x690 [mlx5_core] [<00000000e92e49d7>] mlx5e_rep_update_flows+0x6e4/0x9b0 [mlx5_core] [<00000000f60f5602>] mlx5e_rep_neigh_update+0x39a/0x5d0 [mlx5_core] • https://git.kernel.org/stable/c/1ef3018f5af3da6376fae546e4dfc3f05f063815 https://git.kernel.org/stable/c/486e8de6e233ff2999493533c6259d1cb538653b https://git.kernel.org/stable/c/806401c20a0f9c51b6c8fd7035671e6ca841f6c2 •
CVSS: 7.8EPSS: 0%CPEs: 2EXPL: 0CVE-2021-47198 – scsi: lpfc: Fix use-after-free in lpfc_unreg_rpi() routine
https://notcve.org/view.php?id=CVE-2021-47198
In the Linux kernel, the following vulnerability has been resolved: scsi: lpfc: Fix use-after-free in lpfc_unreg_rpi() routine An error is detected with the following report when unloading the driver: "KASAN: use-after-free in lpfc_unreg_rpi+0x1b1b" The NLP_REG_LOGIN_SEND nlp_flag is set in lpfc_reg_fab_ctrl_node(), but the flag is not cleared upon completion of the login. This allows a second call to lpfc_unreg_rpi() to proceed with nlp_rpi set to LPFC_RPI_ALLOW_ERROR. This results in a use after free access when used as an rpi_ids array index. Fix by clearing the NLP_REG_LOGIN_SEND nlp_flag in lpfc_mbx_cmpl_fc_reg_login(). En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: scsi: lpfc: Fix use-after-free en la rutina lpfc_unreg_rpi() Se detecta un error con el siguiente reporte al descargar el driver: "KASAN: use-after-free en lpfc_unreg_rpi +0x1b1b" El NLP_REG_LOGIN_SEND nlp_flag está configurado en lpfc_reg_fab_ctrl_node(), pero el indicador no se borra al finalizar el inicio de sesión. Esto permite una segunda llamada a lpfc_unreg_rpi() para continuar con nlp_rpi configurado en LPFC_RPI_ALLOW_ERROR. Esto da como resultado un acceso de use after free cuando se usa como índice de matriz rpi_ids. • https://git.kernel.org/stable/c/dbebf865b3239595c1d4dba063b122862583b52a https://git.kernel.org/stable/c/79b20beccea3a3938a8500acef4e6b9d7c66142f • CWE-416: Use After Free •