CVSS: 3.3EPSS: 0%CPEs: 3EXPL: 0CVE-2021-47074 – nvme-loop: fix memory leak in nvme_loop_create_ctrl()
https://notcve.org/view.php?id=CVE-2021-47074
01 Mar 2024 — In the Linux kernel, the following vulnerability has been resolved: nvme-loop: fix memory leak in nvme_loop_create_ctrl() When creating loop ctrl in nvme_loop_create_ctrl(), if nvme_init_ctrl() fails, the loop ctrl should be freed before jumping to the "out" label. In the Linux kernel, the following vulnerability has been resolved: nvme-loop: fix memory leak in nvme_loop_create_ctrl() When creating loop ctrl in nvme_loop_create_ctrl(), if nvme_init_ctrl() fails, the loop ctrl should be freed before jumping ... • https://git.kernel.org/stable/c/3a85a5de29ea779634ddfd768059e06196687aba •
CVSS: 4.6EPSS: 0%CPEs: 5EXPL: 0CVE-2021-47073 – platform/x86: dell-smbios-wmi: Fix oops on rmmod dell_smbios
https://notcve.org/view.php?id=CVE-2021-47073
01 Mar 2024 — In the Linux kernel, the following vulnerability has been resolved: platform/x86: dell-smbios-wmi: Fix oops on rmmod dell_smbios init_dell_smbios_wmi() only registers the dell_smbios_wmi_driver on systems where the Dell WMI interface is supported. While exit_dell_smbios_wmi() unregisters it unconditionally, this leads to the following oops: [ 175.722921] ------------[ cut here ]------------ [ 175.722925] Unexpected driver unregister! [ 175.722939] WARNING: CPU: 1 PID: 3630 at drivers/base/driver.c:194 drive... • https://git.kernel.org/stable/c/1a258e670434f404a4500b65ba1afea2c2b29bba • CWE-99: Improper Control of Resource Identifiers ('Resource Injection') •
CVSS: 5.5EPSS: 0%CPEs: 4EXPL: 0CVE-2021-47071 – uio_hv_generic: Fix a memory leak in error handling paths
https://notcve.org/view.php?id=CVE-2021-47071
01 Mar 2024 — In the Linux kernel, the following vulnerability has been resolved: uio_hv_generic: Fix a memory leak in error handling paths If 'vmbus_establish_gpadl()' fails, the (recv|send)_gpadl will not be updated and 'hv_uio_cleanup()' in the error handling path will not be able to free the corresponding buffer. In such a case, we need to free the buffer explicitly. In the Linux kernel, the following vulnerability has been resolved: uio_hv_generic: Fix a memory leak in error handling paths If 'vmbus_establish_gpadl(... • https://git.kernel.org/stable/c/cdfa835c6e5e87d145f9f632b58843de97509f2b •
CVSS: 5.5EPSS: 0%CPEs: 2EXPL: 0CVE-2021-47070 – uio_hv_generic: Fix another memory leak in error handling paths
https://notcve.org/view.php?id=CVE-2021-47070
01 Mar 2024 — In the Linux kernel, the following vulnerability has been resolved: uio_hv_generic: Fix another memory leak in error handling paths Memory allocated by 'vmbus_alloc_ring()' at the beginning of the probe function is never freed in the error handling path. Add the missing 'vmbus_free_ring()' call. Note that it is already freed in the .remove function. In the Linux kernel, the following vulnerability has been resolved: uio_hv_generic: Fix another memory leak in error handling paths Memory allocated by 'vmbus_a... • https://git.kernel.org/stable/c/cdfa835c6e5e87d145f9f632b58843de97509f2b •
CVSS: 7.8EPSS: 0%CPEs: 9EXPL: 0CVE-2021-47068 – net/nfc: fix use-after-free llcp_sock_bind/connect
https://notcve.org/view.php?id=CVE-2021-47068
29 Feb 2024 — In the Linux kernel, the following vulnerability has been resolved: net/nfc: fix use-after-free llcp_sock_bind/connect Commits 8a4cd82d ("nfc: fix refcount leak in llcp_sock_connect()") and c33b1cc62 ("nfc: fix refcount leak in llcp_sock_bind()") fixed a refcount leak bug in bind/connect but introduced a use-after-free if the same local is assigned to 2 different sockets. This can be triggered by the following simple program: int sock1 = socket( AF_NFC, SOCK_STREAM, NFC_SOCKPROTO_LLCP ); int sock2 = socket(... • https://git.kernel.org/stable/c/a1cdd18c49d23ec38097ac2c5b0d761146fc0109 •
CVSS: 7.8EPSS: 0%CPEs: 4EXPL: 0CVE-2021-47063 – drm: bridge/panel: Cleanup connector on bridge detach
https://notcve.org/view.php?id=CVE-2021-47063
29 Feb 2024 — In the Linux kernel, the following vulnerability has been resolved: drm: bridge/panel: Cleanup connector on bridge detach If we don't call drm_connector_cleanup() manually in panel_bridge_detach(), the connector will be cleaned up with the other DRM objects in the call to drm_mode_config_cleanup(). However, since our drm_connector is devm-allocated, by the time drm_mode_config_cleanup() will be called, our connector will be long gone. Therefore, the connector must be cleaned up when the bridge is detached t... • https://git.kernel.org/stable/c/13dfc0540a575b47b2d640b093ac16e9e09474f6 •
CVSS: 7.8EPSS: 0%CPEs: 10EXPL: 0CVE-2021-47061 – KVM: Destroy I/O bus devices on unregister failure _after_ sync'ing SRCU
https://notcve.org/view.php?id=CVE-2021-47061
29 Feb 2024 — In the Linux kernel, the following vulnerability has been resolved: KVM: Destroy I/O bus devices on unregister failure _after_ sync'ing SRCU If allocating a new instance of an I/O bus fails when unregistering a device, wait to destroy the device until after all readers are guaranteed to see the new null bus. Destroying devices before the bus is nullified could lead to use-after-free since readers expect the devices on their reference of the bus to remain valid. En el kernel de Linux, se ha resuelto la sigui... • https://git.kernel.org/stable/c/f65886606c2d3b562716de030706dfe1bea4ed5e •
CVSS: 6.5EPSS: 0%CPEs: 10EXPL: 0CVE-2021-47060 – KVM: Stop looking for coalesced MMIO zones if the bus is destroyed
https://notcve.org/view.php?id=CVE-2021-47060
29 Feb 2024 — In the Linux kernel, the following vulnerability has been resolved: KVM: Stop looking for coalesced MMIO zones if the bus is destroyed Abort the walk of coalesced MMIO zones if kvm_io_bus_unregister_dev() fails to allocate memory for the new instance of the bus. If it can't instantiate a new bus, unregister_dev() destroys all devices _except_ the target device. But, it doesn't tell the caller that it obliterated the bus and invoked the destructor for all devices that were on the bus. In the coalesced MMIO c... • https://git.kernel.org/stable/c/41b2ea7a6a11e2b1a7f2c29e1675a709a6b2b98d •
CVSS: 5.1EPSS: 0%CPEs: 6EXPL: 0CVE-2021-47058 – regmap: set debugfs_name to NULL after it is freed
https://notcve.org/view.php?id=CVE-2021-47058
29 Feb 2024 — In the Linux kernel, the following vulnerability has been resolved: regmap: set debugfs_name to NULL after it is freed There is a upstream commit cffa4b2122f5("regmap:debugfs: Fix a memory leak when calling regmap_attach_dev") that adds a if condition when create name for debugfs_name. With below function invoking logical, debugfs_name is freed in regmap_debugfs_exit(), but it is not created again because of the if condition introduced by above commit. regmap_reinit_cache() regmap_debugfs_exit() ... regmap_... • https://git.kernel.org/stable/c/5b654b03007917f3f1015b2a5c288c1ea6ae8f65 •
CVSS: 5.5EPSS: 0%CPEs: 8EXPL: 0CVE-2021-47056 – crypto: qat - ADF_STATUS_PF_RUNNING should be set after adf_dev_init
https://notcve.org/view.php?id=CVE-2021-47056
29 Feb 2024 — In the Linux kernel, the following vulnerability has been resolved: crypto: qat - ADF_STATUS_PF_RUNNING should be set after adf_dev_init ADF_STATUS_PF_RUNNING is (only) used and checked by adf_vf2pf_shutdown() before calling adf_iov_putmsg()->mutex_lock(vf2pf_lock), however the vf2pf_lock is initialized in adf_dev_init(), which can fail and when it fail, the vf2pf_lock is either not initialized or destroyed, a subsequent use of vf2pf_lock will cause issue. To fix this issue, only set this flag if adf_dev_in... • https://git.kernel.org/stable/c/25c6ffb249f612c56a48ce48a3887adf57b8f4bd •