CVSS: -EPSS: 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
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. • https://git.kernel.org/stable/c/cdfa835c6e5e87d145f9f632b58843de97509f2b https://git.kernel.org/stable/c/cdd91637d4ef33e2be19a8e16e72e7d00c996d76 https://git.kernel.org/stable/c/d84b5e912212b05f6b5bde9f682046accfbe0354 https://git.kernel.org/stable/c/53486c467e356e06aa37047c984fccd64d78c827 https://git.kernel.org/stable/c/3ee098f96b8b6c1a98f7f97915f8873164e6af9d •
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
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. • https://git.kernel.org/stable/c/cdfa835c6e5e87d145f9f632b58843de97509f2b https://git.kernel.org/stable/c/5f59240cf25b2f7a0fdffc2701482a70310fec07 https://git.kernel.org/stable/c/0b0226be3a52dadd965644bc52a807961c2c26df •
CVSS: 5.5EPSS: 0%CPEs: 3EXPL: 0CVE-2021-47069 – ipc/mqueue, msg, sem: avoid relying on a stack reference past its expiry
https://notcve.org/view.php?id=CVE-2021-47069
In the Linux kernel, the following vulnerability has been resolved: ipc/mqueue, msg, sem: avoid relying on a stack reference past its expiry do_mq_timedreceive calls wq_sleep with a stack local address. The sender (do_mq_timedsend) uses this address to later call pipelined_send. This leads to a very hard to trigger race where a do_mq_timedreceive call might return and leave do_mq_timedsend to rely on an invalid address, causing the following crash: RIP: 0010:wake_q_add_safe+0x13/0x60 Call Trace: __x64_sys_mq_timedsend+0x2a9/0x490 do_syscall_64+0x80/0x680 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x7f5928e40343 The race occurs as: 1. do_mq_timedreceive calls wq_sleep with the address of `struct ext_wait_queue` on function stack (aliased as `ewq_addr` here) - it holds a valid `struct ext_wait_queue *` as long as the stack has not been overwritten. 2. `ewq_addr` gets added to info->e_wait_q[RECV].list in wq_add, and do_mq_timedsend receives it via wq_get_first_waiter(info, RECV) to call __pipelined_op. 3. Sender calls __pipelined_op::smp_store_release(&this->state, STATE_READY). Here is where the race window begins. • https://git.kernel.org/stable/c/0d97a82ba830d89a1e541cc9cd11f1e38c28e416 https://git.kernel.org/stable/c/4528c0c323085e645b8765913b4a7fd42cf49b65 https://git.kernel.org/stable/c/807fa14536b26803b858da878b643be72952a097 https://git.kernel.org/stable/c/a11ddb37bf367e6b5239b95ca759e5389bb46048 https://access.redhat.com/security/cve/CVE-2021-47069 https://bugzilla.redhat.com/show_bug.cgi?id=2267513 • CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition') •
CVSS: -EPSS: 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
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( AF_NFC, SOCK_STREAM, NFC_SOCKPROTO_LLCP ); memset( &addr, 0, sizeof(struct sockaddr_nfc_llcp) ); addr.sa_family = AF_NFC; addr.nfc_protocol = NFC_PROTO_NFC_DEP; bind( sock1, (struct sockaddr*) &addr, sizeof(struct sockaddr_nfc_llcp) ) bind( sock2, (struct sockaddr*) &addr, sizeof(struct sockaddr_nfc_llcp) ) close(sock1); close(sock2); Fix this by assigning NULL to llcp_sock->local after calling nfc_llcp_local_put. This addresses CVE-2021-23134. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/nfc: corrige use-after-free llcp_sock_bind/connect Commits 8a4cd82d ("nfc: corrige la fuga de refcount en llcp_sock_connect()") y c33b1cc62 ("nfc: corrige la fuga de refcount en llcp_sock_bind()") corrigió un error de fuga de recuento en bind/connect pero introdujo un Use-After-Free si el mismo local está asignado a 2 sockets diferentes. Esto puede activarse mediante el siguiente programa simple: int sock1 = socket( AF_NFC, SOCK_STREAM, NFC_SOCKPROTO_LLCP ); int sock2 = conector (AF_NFC, SOCK_STREAM, NFC_SOCKPROTO_LLCP); memset( &addr, 0, sizeof(struct sockaddr_nfc_llcp) ); addr.sa_family = AF_NFC; addr.nfc_protocol = NFC_PROTO_NFC_DEP; bind( sock1, (struct sockaddr*) & addr, sizeof(struct sockaddr_nfc_llcp) ) bind( sock2, (struct sockaddr*) & addr, sizeof(struct sockaddr_nfc_llcp) ) close(sock1); cerrar(calcetín2); Solucione este problema asignando NULL a llcp_sock->local después de llamar a nfc_llcp_local_put. Esto aborda CVE-2021-23134. • https://git.kernel.org/stable/c/a1cdd18c49d23ec38097ac2c5b0d761146fc0109 https://git.kernel.org/stable/c/18013007b596771bf5f5e7feee9586fb0386ad14 https://git.kernel.org/stable/c/538a6ff11516d38a61e237d2d2dc04c30c845fbe https://git.kernel.org/stable/c/adbb1d218c5f56dbae052765da83c0f57fce2a31 https://git.kernel.org/stable/c/c89903c9eff219a4695e63715cf922748d743f65 https://git.kernel.org/stable/c/6fb003e5ae18d8cda4c8a1175d9dd8db12bec049 https://git.kernel.org/stable/c/8c9e4971e142e2899606a2490b77a1208c1f4638 https://git.kernel.org/stable/c/c33b1cc62ac05c1dbb1cdafe2eb66da01 •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2021-47067 – soc/tegra: regulators: Fix locking up when voltage-spread is out of range
https://notcve.org/view.php?id=CVE-2021-47067
In the Linux kernel, the following vulnerability has been resolved: soc/tegra: regulators: Fix locking up when voltage-spread is out of range Fix voltage coupler lockup which happens when voltage-spread is out of range due to a bug in the code. The max-spread requirement shall be accounted when CPU regulator doesn't have consumers. This problem is observed on Tegra30 Ouya game console once system-wide DVFS is enabled in a device-tree. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: soc/tegra: regulators: se corrigió el bloqueo cuando la dispersión de voltaje está fuera de rango. Se corrigió el bloqueo del acoplador de voltaje que ocurre cuando la dispersión de voltaje está fuera de rango debido a un error en el código. . • https://git.kernel.org/stable/c/783807436f363e5b1ad4d43ba7debbedfcadbb99 https://git.kernel.org/stable/c/a1ad124c836816fac8bd5e461d36eaf33cee4e24 https://git.kernel.org/stable/c/dc4452867200fa94589b382740952b58aa1c3e6c https://git.kernel.org/stable/c/ff39adf5d31c72025bba799aec69c5c86d81d549 https://git.kernel.org/stable/c/ef85bb582c41524e9e68dfdbde48e519dac4ab3d •