Page 443 of 3280 results (0.019 seconds)

CVSS: 2.3EPSS: 0%CPEs: 5EXPL: 0

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 driver_unregister+0x38/0x40 ... [ 175.723089] Call Trace: [ 175.723094] cleanup_module+0x5/0xedd [dell_smbios] ... [ 175.723148] ---[ end trace 064c34e1ad49509d ]--- Make the unregister happen on the same condition the register happens to fix this. • https://git.kernel.org/stable/c/1a258e670434f404a4500b65ba1afea2c2b29bba https://git.kernel.org/stable/c/75cfc833da4a2111106d4c134e93e0c7f41e35e7 https://git.kernel.org/stable/c/6fa78a6b9a3beb676a010dc489c1257f7e432525 https://git.kernel.org/stable/c/0cf036a0d325200e6c27b90908e51195bbc557b1 https://git.kernel.org/stable/c/8d746ea7c687bab060a2c05a35c449302406cd52 https://git.kernel.org/stable/c/3a53587423d25c87af4b4126a806a0575104b45e https://access.redhat.com/security/cve/CVE-2021-47073 https://bugzilla.redhat.com/show_bug.cgi?id=2267518 • CWE-99: Improper Control of Resource Identifiers ('Resource Injection') •

CVSS: -EPSS: 0%CPEs: 4EXPL: 0

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: -EPSS: 0%CPEs: 2EXPL: 0

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: 0

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: 0

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 •